tegwick
b081d39da1
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a06e82-3e08-7042-a79d-438ac6eed8db
86 lines
4.5 KiB
Markdown
86 lines
4.5 KiB
Markdown
# 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.
|