# 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:

```bash
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

```bash
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.