info-tech-canon/docs/canon-consumption.md
tegwick b081d39da1
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 3s
Implement canon conformance and maintenance optimizations
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06e82-3e08-7042-a79d-438ac6eed8db
2026-09-05 00:50:09 +02:00

4.5 KiB

Reproducible canon consumption

The Python service and canon corpus have independent versions. Install the service into a virtual environment and supply a pinned corpus checkout with --root /path/to/corpus/infospace or INFO_TECH_CANON_ROOT. Source-tree users may use make targets; BENCH_SOURCE is an optional development override. Installed use does not depend on adjacent source directories.

Installation boundary

The service requires Python 3.12+, PyYAML, jsonschema, and the reference-data modules of infospace-bench 0.1.0. Its distribution is discovered through Python's installed module search path. A narrow adapter avoids executing the upstream initializer, which imports unrelated database/engine integrations.

The upstream bench distribution still declares workstation-specific dependencies for its full application. Until its owner separates the reference-data package, use reviewed local wheels and install the narrow service dependencies explicitly:

python3 -m venv /path/to/venv
/path/to/venv/bin/pip install PyYAML jsonschema
/path/to/venv/bin/pip install --no-deps --no-index /path/to/infospace_bench-0.1.0-py3-none-any.whl /path/to/info_tech_canon-0.1.0-py3-none-any.whl
/path/to/venv/bin/info-tech-canon --root /path/to/canon/infospace inspect

Pin wheel hashes and the corpus revision in consumer deployment records. This procedure supports canon reference operations, not the complete bench application. A normal transitive dependency installation remains an upstream packaging limitation. The corpus is supplied separately and includes its root governance files and provenance inputs (including seeds/ and demand/) when whole-repository validation is required.

Declaration and bundle workflow

info-tech-canon --root /path/to/canon/infospace emission-review /path/to/source-declaration.yaml
info-tech-canon --root /path/to/canon/infospace export-emission-contract /path/to/bundles

The export contains the standard, schema, illustrative example, and a manifest of SHA-256 file hashes. Its tar filename contains the archive SHA-256. Identical inputs produce identical bytes; a different contract produces a different name. Existing different contents at the computed path cause failure. The export is a local artifact, not evidence of remote publication or independent adoption.

The shared validator accepts YAML or JSON, applies the schema, and additionally checks unique source_id values. A schema-only consumer must implement that uniqueness check too. Unsupported versions and malformed forms fail. Validation does not assess operational truth or importing-profile policy.

Independent adoption gate

File owner-authored results under feedback/ using its existing intake process. Each implementation's evidence must include:

  • source repository, accountable owner, implementation revision, declaration path;
  • contract version, bundle SHA-256, and schema SHA-256;
  • importing consumer/profile revision and its additional policy checks;
  • positive result for the actual source-owned declaration;
  • negative results for unsupported versions, duplicate IDs, missing windows, and malformed heartbeat/reconciliation forms;
  • distinction between locally tested behavior and observed deployed behavior, with evidence references and dates for each claim.

Two records must represent independently implemented sources; copying the illustrative example twice does not count. A human/owner review must assess independence and operational claims. Draft promotion remains pending in INFO-WP-0019-T06 until this evidence exists. No new profile or pattern should be created solely to fill an inventory: use recurring consumer demand and recorded CARING gaps to select the next semantic work.

Maintenance and coverage

validation-coverage lists artifact checks and unproven properties. scope-inventory derives counts and model/standard IDs from the registry. make check-generated renders in a temporary copy and reports missing/stale assets without repairing the checkout. make refresh performs regeneration. make check runs tests, freshness, canon validation, and profile validation. Work-record projections remain owned by statehub fix-consistency.

Validation reports written with validate --write include UTC time, Git revision, dirty status, and a digest of all infospace files except validation reports. The digest captures uncommitted corpus changes; Git revision alone does not. benchmark-reads measures ten uncached inspections. Use measurements and an explicit latency target before introducing a cache.