tegwick
b081d39da1
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a06e82-3e08-7042-a79d-438ac6eed8db
115 lines
7 KiB
Markdown
115 lines
7 KiB
Markdown
# 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](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](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](docs/canon-consumption.md).
|
||
|
||
## 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](history/2026-09-05_002437+0200-scope-against-intent.md).
|