Implement canon conformance and maintenance optimizations
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a06e82-3e08-7042-a79d-438ac6eed8db
This commit is contained in:
parent
a2e7f22d8d
commit
b081d39da1
64 changed files with 4491 additions and 373 deletions
308
SCOPE.md
308
SCOPE.md
|
|
@ -1,241 +1,115 @@
|
|||
# SCOPE
|
||||
|
||||
## Current Repository Scope
|
||||
Reviewed: 2026-09-05 (Europe/Berlin), including the uncommitted working tree.
|
||||
|
||||
This repository currently contains the seed structure for **InfoTechCanon**: an evolving, markdown-first canon for building interoperable, adaptable, and extensible information-processing systems.
|
||||
## Current repository scope
|
||||
|
||||
At this stage, the repository is not yet a fully validated standards system. It is a **seed corpus** of kernel documents, domain models, specialized standards, and integration guidance that together define the first-generation InfoTechCanon kernel.
|
||||
InfoTechCanon maintains one concrete, Markdown-first, machine-readable canon
|
||||
under `infospace/`, with a Python service for inspection, validation, retrieval,
|
||||
and generation. It has progressed beyond its seed corpus to a **service baseline
|
||||
with executable proofs and mixed artifact maturity**.
|
||||
|
||||
---
|
||||
The working-tree canon version is `0.7.0`; the Python package version is
|
||||
`0.1.0`. These are separate version surfaces. Many models remain `RC1-seed`;
|
||||
ITC-CAP is a frozen draft at `0.4.0`, and Emission Cadence is a draft document
|
||||
at `0.1.0` with wire schema version `0.1`. This is not yet a stable,
|
||||
ecosystem-wide conformance release.
|
||||
|
||||
## Current Purpose
|
||||
## Ownership and boundaries
|
||||
|
||||
The repository currently serves to:
|
||||
Following [INTENT.md](INTENT.md), this repository occupies the Taxonomy layer:
|
||||
it owns shared terminology, generic semantic contracts, compatibility rules,
|
||||
and reference artifacts for independently owned systems.
|
||||
|
||||
- collect the first generation of InfoTechCanon standards and models,
|
||||
- define the semantic boundaries between domains,
|
||||
- preserve orthogonality between concepts,
|
||||
- provide seed structures for mappings, profiles, patterns, assimilation, validation, and agent use,
|
||||
- support future machine-readable extraction,
|
||||
- and act as the first major use case for markdown-based infospaces and related tooling.
|
||||
The CLI, library, and local read-only HTTP API serve and check those artifacts.
|
||||
They do not establish ownership of consumer runtime state, enforcement,
|
||||
observation, or orchestration. NetKingdom owns its security architecture and
|
||||
importing security profiles. Sources own emission-cadence instances; observers
|
||||
own evaluation and findings; importing profiles own additional policy requirements.
|
||||
|
||||
---
|
||||
## Implemented canon content
|
||||
|
||||
## Current Kernel
|
||||
| Surface | Current responsibility |
|
||||
| --- | --- |
|
||||
| `infospace/kernel/` | Core mechanisms for artifacts, ownership, relationships, mappings, assimilation, profiles, patterns, conformance, provenance, and interfaces; kernel map. |
|
||||
| `infospace/models/` | Information Space, Landscape, Organization, Governance, Task, Access Control, Security, Data, DevSecOps, Network, Observability, and Capability models. |
|
||||
| Extensions and catalogs | PURPOSES/Purpose and Demand governance extension; EvidenceBasis; AttributeValueType; ITC-CAP capabilities, requirements, provisions, maturity, economics, and evidence relationships. |
|
||||
| `infospace/standards/` | Tagging, CARING access governance, Repository Layout, and draft Emission Cadence. |
|
||||
| `infospace/profiles/small-saas/` | Executable example linking service, system, tenants, user, team, data, deployment, task, policy, control, evidence, incident, and capability requirements/provisions. |
|
||||
| `infospace/patterns/` | Intent–Scope–Purposes, PracticePattern scheme, InterfaceDeprecationStrangler, and AgenticDrivesFunctional. |
|
||||
| Mappings and assimilation | Mapping artifacts and source-preserving workspaces for IT Capability Canon and Emission Cadence, including comparisons, dispositions, gaps, and open questions. |
|
||||
| `infospace/evaluations/` | Evaluation/comparison packs for user-engine, railiance-fabric, repo-scoping, and repository-layout. These prepare adoption and review; they do not certify deployed consumers. |
|
||||
| CARING Kubernetes RBAC benchmark | Native-concept mappings, structured access descriptors, findings, conflicts, and proposed improvements. |
|
||||
| `infospace/agent/` | Generated retrieval indexes and artifact briefs, consumer briefs, interface-card template, alignment review kit, and consumer workplan template. |
|
||||
|
||||
The current kernel consists of:
|
||||
The root is the service and governance shell. `seeds/` preserves provenance.
|
||||
`incoming/`, `demand/`, and `feedback/` distinguish source material, consumer
|
||||
needs, and utility evidence. Workplans and intake records track work;
|
||||
`history/` holds dated assessments. Generated navigation lives under
|
||||
`infospace/indexes/`, `infospace/views/`, and `infospace/agent/`.
|
||||
|
||||
```text
|
||||
kernel/
|
||||
InfoTechCanonCore.md
|
||||
InfoTechCanonKernelMap.md
|
||||
```
|
||||
## Implemented service and checks
|
||||
|
||||
### InfoTechCanonCore
|
||||
`src/info_tech_canon/` provides an importable Python service, JSON-first CLI,
|
||||
and read-only HTTP API, defaulting to `127.0.0.1:8765`. Operations include
|
||||
artifact/model/standard inspection, graph export (JSON or Mermaid), canon and
|
||||
profile validation, capability-record review, generated-view retrieval, and
|
||||
alignment-review materials. CLI maintenance commands generate indexes, trees,
|
||||
and agent briefs. Usage and endpoints are in [README.md](README.md).
|
||||
|
||||
Defines shared canon mechanisms:
|
||||
Validation checks registered paths, artifact IDs and relationship targets,
|
||||
collection metrics, required schema presence, and selected content contracts.
|
||||
Specialized checks cover capability records/catalogs, practice patterns,
|
||||
consumer packs, and the built-in Emission Cadence example. JSON Schemas exist
|
||||
for multiple artifact types, but general schema-to-instance validation and
|
||||
semantic conformance are not complete across the corpus.
|
||||
|
||||
- canon artifacts,
|
||||
- concepts,
|
||||
- concept ownership,
|
||||
- relationships,
|
||||
- mappings,
|
||||
- assimilation,
|
||||
- profiles,
|
||||
- patterns,
|
||||
- validation rules,
|
||||
- conformance levels,
|
||||
- versioning,
|
||||
- provenance,
|
||||
- agent briefs,
|
||||
- and Canon Interface Cards.
|
||||
Dependencies are Python 3.12+, PyYAML, jsonschema, and `infospace-bench`.
|
||||
The loader discovers an installed bench distribution. An explicit `--root` or
|
||||
`INFO_TECH_CANON_ROOT` selects a separately supplied corpus. Narrow wheel
|
||||
installation is supported; upstream bench's full transitive dependency metadata
|
||||
still contains workstation-specific paths. See
|
||||
[consumption instructions](docs/canon-consumption.md).
|
||||
|
||||
### InfoTechCanonKernelMap
|
||||
## Verified baseline and limits
|
||||
|
||||
Shows how the first-generation standards and models fit together, including the position of CARING as a specialized access-governance standard.
|
||||
After INFO-WP-0019 implementation, `make check` passed **36 tests** and
|
||||
verified **77 generated assets**. Read-only CLI validation
|
||||
reported **76 registered artifacts, 315 relationships, zero errors and zero
|
||||
warnings**. Small-SaaS validation passed with **15 artifacts/payloads**.
|
||||
|
||||
---
|
||||
The ownership calculation reports 129 entries and no cross-owner conflicts,
|
||||
but derives entries from artifact titles and explicit `owned_concepts`
|
||||
frontmatter. It does not establish ownership of every concept in prose.
|
||||
Collection coverage metrics measure the registered corpus, not fulfillment
|
||||
of every intent commitment.
|
||||
|
||||
## Current Models
|
||||
Current limitations include:
|
||||
|
||||
The repository currently includes seed models for:
|
||||
- incomplete concept extraction and enforcement of concept-level imports;
|
||||
- uneven schema depth and validation coverage, including no formal
|
||||
CARINGAccessDescriptor schema or complete effective-access calculus;
|
||||
- limited external mapping and independent consumer interoperability evidence;
|
||||
- interface templates and evaluation packs without a complete set of
|
||||
source-owned, version-pinned consumer declarations;
|
||||
- draft promotion and compatibility questions, including the requirement for
|
||||
two independent Emission Cadence source implementations;
|
||||
- upstream full-application packaging limitations and consumer-owned adoption evidence.
|
||||
|
||||
```text
|
||||
models/
|
||||
information-space/
|
||||
landscape/
|
||||
organization/
|
||||
governance/
|
||||
task/
|
||||
access-control/
|
||||
security/
|
||||
data/
|
||||
devsecops/
|
||||
network/
|
||||
observability/
|
||||
```
|
||||
INFO-WP-0019 adds reusable arbitrary Emission Cadence declaration validation,
|
||||
mapping schema checks, explicit ownership-conflict enforcement, a validation
|
||||
coverage report, content-addressed contract export, generated-asset freshness
|
||||
checks, scope inventory, and validation source/time evidence. These mechanisms
|
||||
do not close the semantic or independent-adoption gaps listed above.
|
||||
|
||||
These models define broad domain structures.
|
||||
## Exclusions and evolution
|
||||
|
||||
| Model | Current Responsibility |
|
||||
|---|---|
|
||||
| Information Space | Markdown-first knowledge packaging, retrieval, links, chunks, indexes, agent briefs |
|
||||
| Landscape | IT landscapes, services, systems, runtime resources, infrastructure context |
|
||||
| Organization | Actors, roles, teams, membership, responsibility, authority, accountability |
|
||||
| Governance | Policies, rules, decisions, controls, risk, evidence, exceptions, assurance |
|
||||
| Task | Work items, options, tasks, actions, blockers, dependencies, commitment, outcomes |
|
||||
| Access Control | Subjects, principals, permissions, grants, authorization decisions, enforcement |
|
||||
| Security | Threats, weaknesses, vulnerabilities, findings, exposure, attack paths, incidents |
|
||||
| Data | Datasets, schemas, data products, classification, lineage, quality, contracts |
|
||||
| DevSecOps | Source-to-artifact-to-release-to-deployment delivery flow and evidence |
|
||||
| Network | Addressing, topology, routing, policy, reachability, exposure, network state |
|
||||
| Observability | Telemetry, logs, metrics, traces, alerts, SLOs, health, operational evidence |
|
||||
This repository does not replace external standards, mandate one universal
|
||||
enterprise model, operate consumer systems, enforce NetKingdom policy, or
|
||||
provide production observability or authorization services. A complete
|
||||
ontology and exhaustive external-standard mappings are not current deliverables.
|
||||
|
||||
---
|
||||
|
||||
## Current Specialized Standards
|
||||
|
||||
The repository currently includes specialized standards for:
|
||||
|
||||
```text
|
||||
standards/
|
||||
tagging/
|
||||
caring/
|
||||
```
|
||||
|
||||
| Standard | Current Responsibility |
|
||||
|---|---|
|
||||
| Tagging | Tag identity, schemes, namespaces, assignments, mappings, validation |
|
||||
| CARING | Orthogonal access-governance analysis using canonical roles, planes, exposure modes, derived and induced capabilities |
|
||||
|
||||
---
|
||||
|
||||
## Current Structural Assumptions
|
||||
|
||||
The current repository structure assumes the distinction:
|
||||
|
||||
```text
|
||||
Kernel
|
||||
Defines how the canon works.
|
||||
|
||||
Models
|
||||
Define broad domain structures.
|
||||
|
||||
Standards
|
||||
Define cross-cutting conventions, mechanisms, or named analytical/design frameworks.
|
||||
|
||||
Profiles
|
||||
Constrain models and standards for concrete implementation contexts.
|
||||
|
||||
Patterns
|
||||
Describe recurring practical solutions.
|
||||
|
||||
Mappings
|
||||
Relate InfoTechCanon concepts to external bodies of knowledge.
|
||||
|
||||
Assimilation
|
||||
Analyzes external knowledge bodies and turns them into mappings, gaps, conflicts, and proposed changes.
|
||||
|
||||
Views
|
||||
Provide generated or curated navigation over canon artifacts.
|
||||
|
||||
Agent
|
||||
Provides compact, retrieval-optimized guidance for AI agents and tools.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Current Non-Goals
|
||||
|
||||
The current repository does not yet provide:
|
||||
|
||||
- a complete ontology,
|
||||
- complete YAML/JSON schemas for all artifact types,
|
||||
- automated validation tooling,
|
||||
- fully extracted concept pages,
|
||||
- finalized mappings to external standards,
|
||||
- complete application profiles,
|
||||
- complete agent retrieval indexes,
|
||||
- mature conformance tests,
|
||||
- or a stable release of the InfoTechCanon.
|
||||
|
||||
The current scope is seed-level structure and consolidation.
|
||||
|
||||
---
|
||||
|
||||
## Current Known Duplication
|
||||
|
||||
The current seed standards still repeat some generic sections that should eventually be centralized in `InfoTechCanonCore`, including:
|
||||
|
||||
- mapping model,
|
||||
- assimilation model,
|
||||
- profile format,
|
||||
- conformance levels,
|
||||
- validation rule format,
|
||||
- repository placement,
|
||||
- agent brief requirements,
|
||||
- Canon Interface Card usage,
|
||||
- lifecycle statuses.
|
||||
|
||||
This duplication is accepted for the seed phase but should be reduced during refactoring.
|
||||
|
||||
---
|
||||
|
||||
## Current Refactoring Priorities
|
||||
|
||||
Near-term work should focus on:
|
||||
|
||||
1. moving repeated generic mechanisms into Core,
|
||||
2. creating machine-readable schemas,
|
||||
3. extracting concept pages from seed standards,
|
||||
4. creating global indexes,
|
||||
5. creating agent briefs,
|
||||
6. creating first application profiles,
|
||||
7. creating formal assimilation workspaces,
|
||||
8. running CARING as the first full benchmark assimilation,
|
||||
9. validating concept ownership across the kernel,
|
||||
10. and creating Canon Interface Cards for initial tools and repositories.
|
||||
|
||||
---
|
||||
|
||||
## First Validation Targets
|
||||
|
||||
The first validation targets should be:
|
||||
|
||||
```text
|
||||
1. Concept ownership table
|
||||
2. Cross-standard import matrix
|
||||
3. Kernel dependency graph
|
||||
4. CARING access descriptor schema
|
||||
5. Mapping schema
|
||||
6. Profile schema
|
||||
7. Agent brief schema
|
||||
8. Repository layout validation
|
||||
9. Internal link validation
|
||||
10. Duplicate concept detection
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Current Maturity
|
||||
|
||||
The repository is currently at:
|
||||
|
||||
```text
|
||||
Maturity: Seed Kernel
|
||||
Status: Pre-release consolidation
|
||||
Primary use: Human/agent reference and refactoring foundation
|
||||
```
|
||||
|
||||
The next maturity target is:
|
||||
|
||||
```text
|
||||
Maturity: Kernel RC1
|
||||
Condition:
|
||||
Core mechanisms centralized,
|
||||
standards indexed,
|
||||
concept ownership explicit,
|
||||
first profiles and mappings created,
|
||||
CARING assimilation completed,
|
||||
and basic validation scripts available.
|
||||
```
|
||||
Further semantic coverage, stronger conformance, and consumer adoption are
|
||||
consistent with intent but require follow-up work. Evidence, gaps, and
|
||||
optimization options are recorded in the
|
||||
[2026-09-05 scope assessment](history/2026-09-05_002437+0200-scope-against-intent.md).
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue