info-tech-canon/SCOPE.md

SCOPE

Reviewed: 2026-09-05 (Europe/Berlin), including the uncommitted working tree.

Current repository scope

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.

Ownership and boundaries

Following INTENT.md, this repository occupies the Taxonomy layer: it owns shared terminology, generic semantic contracts, compatibility rules, and reference artifacts for independently owned systems.

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

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 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/.

Implemented service and checks

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.

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.

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.

Verified baseline and limits

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 limitations include:

• 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.

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.

Exclusions and evolution

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.

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.