Canon 0.4.0: joinable consumer proof and EvidenceBasis

§10.3 now accepts a consumer record that validates against the live catalog; resource-control's backup restatement is that proof. ITC-GOV gains EvidenceBasis in tiers (invoiced and measured are peers) and ITC-CAP requires it on every consumption row (CAP-R10).
2026-08-15 19:14:11 +02:00 · 2026-08-15 19:14:11 +02:00 · f2d216af53
commit f2d216af53
parent ce17dc4d4d
29 changed files with 605 additions and 127 deletions
--- a/infospace/models/capability/InfoTechCanonCapabilityModel.md
+++ b/infospace/models/capability/InfoTechCanonCapabilityModel.md
@ -7,7 +7,7 @@ standard_family: InfoTechCanon
 repository_context: info-tech-canon
 recommended_path: models/capability/InfoTechCanonCapabilityModel.md
 status: proposed
-version: 0.2.0
+version: 0.3.0
 source_version: "0.1"
 source_body: Information Technology Capability Canon (ITCC)
 source_file: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md
@ -55,7 +55,7 @@ updated_at: 2026-08-15

 **Short Name:** `ITC-CAP`
 **Document Status:** Proposed (assimilated, not yet promoted)
-**Version:** 0.2.0
+**Version:** 0.3.0
 **Document Type:** InfoTechCanon Domain Model
 **Machine-readable catalog:** `models/capability/capabilities.yaml`
 **Provenance:** adapted from ITCC v0.1 — see `assimilation/it-capability-canon`
@ -253,21 +253,30 @@ provision:
    - class: S
      quantity: {value: 50, unit: GB}
      period: month
+      basis: measured
    - class: H
      quantity: {value: 1.0, unit: hour}
      period: month
      supply: internal
+      basis: assumed
    - class: P
      quantity: {value: 1, unit: unit}
      period: month
      supply: external
+      basis: quoted
    - class: I
      quantity: unknown
+      basis: unknown
 ```

 Unknown consumption MUST be recorded as `unknown`, never as zero. Zero means
 "measured and none"; unknown means "not yet measured or not applicable."

+Every consumption row MUST declare an **EvidenceBasis** (ITC-GOV): how the
+quantity was obtained. The closed scale, propagation rule, and decision
+grades are owned there; this model imports them. A row with basis `unknown`
+MUST NOT carry a quantity. A row with any other basis MUST carry a quantity.
+
 A provision MAY override a class's default `supply` and `capacity_behaviour`
 (for example contracted operator time recorded as `H` with `supply: external`).

@ -374,6 +383,10 @@ The canon does **not** declare a `substitutes_for` relation or an exchange rate
 between classes. If `H` and `I` appear on the same provision in native units,
 substitution is observable from the time series.

+A consumption row without a basis is invalid. Collapsing `measured` and
+`assumed` into one number is the same defect as collapsing hours and tokens
+into currency: it destroys the information a decision actually rests on.
+
 ---

 # 5. Normative Rules
@ -417,6 +430,13 @@ native unit. Unknown MUST be recorded as `unknown`, never as zero.
 MUST be declared on the required capability. A target is an intended value, not
 a measurement.

+**CAP-R10** A CapabilityConsumption MUST declare `basis` from the ITC-GOV
+EvidenceBasis catalog. Basis `unknown` MUST NOT carry a quantity; any other
+basis MUST. A derived value MUST name its inputs; its effective basis is the
+weakest *tier* among those inputs (ITC-GOV). Members of the same tier do not
+rank against each other. Evidence items on a provision SHOULD declare a basis
+on the same scale.
+
 ---

 # 6. Admission Rules
@ -499,7 +519,7 @@ model. This is accepted at `proposed` status and tracked as OQ-5.
 | Model | Boundary |
 |---|---|
 | ITC-LAND | Owns services, technologies, runtime resources, and *observed* SLOs. ITC-CAP names abilities and *intended* requirement targets; ITC-LAND names the things that provide and implement them. `BusinessCapability` / `ProductCapability` in ITC-LAND §11 should resolve to references here. |
-| ITC-GOV | Owns policy, control, evidence, assurance. ITC-CAP names capability evidence *hooks*, not evidence semantics. Capability requirements are typed demand signals from the Purpose and Demand extension. |
+| ITC-GOV | Owns policy, control, evidence, assurance, and **EvidenceBasis** (how a quantity was obtained). ITC-CAP names capability evidence *hooks*, not evidence semantics. A `CapabilityConsumption` MUST declare an EvidenceBasis. Capability requirements are typed demand signals from the Purpose and Demand extension. |
 | ITC-ACCESS | Owns subject, principal, permission, grant, decision. `identity.*` capabilities are abilities over those mechanisms. |
 | CARING | Access-governance analysis. May import `identity.*` ids; ITC-CAP takes no position on access-governance analysis. |
 | ITC-OBS | Owns telemetry, SLO measurement, health — the source of measured maturity evidence. |
@ -518,8 +538,22 @@ This model enters the canon at status `proposed`. Promotion requires:
   0.2.1**: the Security & Governance navigation domain was split into `security`
   and `governance`, aligning every id with its domain and changing no id;
 2. publication of `capability.schema.yaml` validating contracts;
-3. at least one canon Profile expressing a real capability requirement set with
-   evidence;
+3. at least one **joinable proof** that a real capability requirement set has
+   been expressed with provisions and evidence. A proof is either:
+
+   - a canon Profile containing such a set, or
+   - a consumer record that validates against the live catalog (capability
+     ids, profiles, quality dimensions, evidence hooks, resource classes,
+     native units, and constraint predicates) and is cited from this
+     repository as PurposeFit evidence under `feedback/`.
+
+   Operational facts stay in the consumer repo. The join is the capability
+   id (CAP-R5). A fictional in-repo example is a weaker proof than a
+   consumer record that already fails or passes against this catalog.
+
+   **Met 2026-08-15** by resource-control
+   `data/capability/platform-audit-storage.json` (commit `13c2b82`), cited
+   in `feedback/2026-08-15-resource-control-cap-restatement.md`.
 4. formal mapping artifacts under `infospace/mappings/` for each anchor.

 Tracked in `ITC-WP-0014`.
@ -544,3 +578,7 @@ the contract onto the provision; requirements gained profile, targets, and
 constraints; class `H` added; `P` narrowed; `I` recharacterised; consumption
 records use native units. See the decision record in
 `assimilation/it-capability-canon/ASSIMILATION.md`.
+
+Version 0.3.0 (canon 0.4.0) accepts a consumer record that validates against
+the live catalog as a promotion proof (§10.3), and requires EvidenceBasis on
+every consumption row (CAP-R10). EvidenceBasis is owned by ITC-GOV.
--- a/infospace/models/capability/capabilities.yaml
+++ b/infospace/models/capability/capabilities.yaml
@ -12,9 +12,9 @@ canon:
  name: InfoTechCanon Capability Model — Capability Catalog
  short_name: ITC-CAP
  artifact_id: model/capability
-  version: 0.2.0
+  version: 0.3.0
  status: proposed
-  canon_version: 0.3.0
+  canon_version: 0.4.0
  purpose: Canonical, implementation-independent catalog of the abilities an information system may require
    or provide.
  normative_document: models/capability/InfoTechCanonCapabilityModel.md
--- a/infospace/models/governance/InfoTechCanonGovernanceModel.md
+++ b/infospace/models/governance/InfoTechCanonGovernanceModel.md
@ -1066,6 +1066,53 @@ meeting decision
 audit sample
 ```

+A quantity offered as evidence MUST declare an **EvidenceBasis** (§11.34a)
+so a decision can be graded by the weakest thing it actually rests on.
+
+---
+
+## 11.34a EvidenceBasis
+
+An **EvidenceBasis** is how a quantity was obtained. A counted object and an
+assumed hourly rate are both numbers; they are not both knowledge.
+
+The closed vocabulary is held in `models/governance/evidence-basis.yaml` and
+is not restated as a second list here. Strength is a **tier**, not a total
+order: `invoiced` and `measured` are peers. `invoiced`, `measured`, and
+`quoted` are **evidenced**. Everything below that tier is inference.
+
+Normative rules:
+
+- A derived value is only as strong as its weakest input, compared by
+  tier. Members of the same tier do not rank against each other.
+- Basis `unknown` carries no quantity and MUST name the gap and its owner.
+  Any other basis MUST carry a quantity. Zero means measured-and-none;
+  unknown means not measured.
+- A derived value MUST record its inputs. Only a derived value may.
+- `invoiced` names a booked financial fact owned by the financial counterpart
+  (`fin-hub`). This model does not originate booked costs.
+
+Optional qualifiers: `proxy_for` (the value measures a different quantity
+than the one being reasoned about) and `observed_at` (the measurement has an
+age).
+
+A set of load-bearing values has a **decision grade**: `evidenced`,
+`projected`, `indicative`, or `insufficient`. The grade is no stronger than
+the weakest resolved basis.
+
+EvidenceBasis is not the intended/declared/applied/observed/assessed state
+qualifier (assimilation OQ-3). Those name *which world* a claim is about.
+This names *how a number* in that world was produced.
+
+Imported by ITC-CAP `CapabilityConsumption` (CAP-R10). Reusable on any
+measured or modelled quantity — actuals, thresholds, forecasts — without
+those records becoming capability artifacts.
+
+**Provenance.** Adapted from consumer demand `demand/EvidenceBasis.md`
+(resource-control `docs/evidence-basis.md` / `tools/basis.py`), 2026-08-15.
+The first application graded a provider comparison `indicative` that had
+been stated to the cent.
+
 ---

 ## 11.35 Assertion
--- a/infospace/models/governance/evidence-basis.yaml
+++ b/infospace/models/governance/evidence-basis.yaml
@ -0,0 +1,110 @@
+# InfoTechCanon Evidence Basis Catalog
+#
+# How a quantity was obtained. Owned by ITC-GOV; imported by CapabilityConsumption
+# (CAP-R10) and reusable on any measured or modelled value.
+#
+# Adapted from demand/EvidenceBasis.md (resource-control). Strength is a tier,
+# not a total order: invoiced and measured are peers. The consumer's first
+# implementation used a strict list rank and corrected it.
+canon:
+  id: itc-gov-evidence-basis
+  name: InfoTechCanon Evidence Basis
+  artifact_id: catalog/evidence-basis
+  version: 0.1.0
+  status: draft
+  canon_version: 0.4.0
+  owner: model/governance
+  purpose: Closed scale for how a quantity was obtained, with a propagation rule
+    and decision grades. Tiers, not a spurious total order.
+  normative_document: models/governance/InfoTechCanonGovernanceModel.md
+  provenance:
+    demand: demand/EvidenceBasis.md
+    consumer: resource-control
+    consumer_docs:
+      - docs/evidence-basis.md
+      - tools/basis.py
+bases:
+  - id: invoiced
+    tier: evidenced
+    description: Taken from an authoritative financial record. This canon names
+      the basis; it does not originate booked costs, tax, or currency semantics.
+  - id: measured
+    tier: evidenced
+    description: Directly observed from the authoritative system.
+  - id: quoted
+    tier: evidenced
+    description: Stated by a provider or counterparty in a citable source.
+  - id: derived
+    tier: null
+    description: Computed from other values by a stated rule. Not a resolved
+      tier — effective basis is the weakest input.
+  - id: projected
+    tier: projected
+    description: Interpolated between, or extrapolated beyond, observations.
+  - id: estimated
+    tier: judgement
+    description: Human judgement, neither observed nor computed.
+  - id: assumed
+    tier: judgement
+    description: A modelling constant chosen by the author.
+  - id: unknown
+    tier: unknown
+    description: No value exists. MUST NOT carry a quantity. MUST name the gap
+      and its owner.
+# Strongest to weakest. Members of one tier are peers: weakest() among only
+# invoiced and measured MUST NOT imply a ranking.
+tiers:
+  - id: evidenced
+    rank: 0
+    members: [invoiced, measured, quoted]
+    note: invoiced and measured are peers. quoted is evidenced for grading but
+      does not outrank or sit below a measurement of a different quantity.
+  - id: projected
+    rank: 1
+    members: [projected]
+  - id: judgement
+    rank: 2
+    members: [estimated, assumed]
+    note: both yield decision grade indicative; they are not ranked against
+      each other.
+  - id: unknown
+    rank: 3
+    members: [unknown]
+rules:
+  - id: weakest-input-wins
+    statement: A derived value is only as strong as its weakest input, compared
+      by tier. Members of the same tier do not rank against each other.
+  - id: unknown-is-not-zero
+    statement: Basis unknown carries no quantity. Any other basis MUST carry a
+      quantity. Zero means measured-and-none; unknown means not measured.
+  - id: derived-names-inputs
+    statement: A derived value MUST record derived_from. Only a derived value
+      MAY record derived_from.
+  - id: invoiced-not-originated
+    statement: invoiced names a booked fact owned elsewhere. This catalog does
+      not define ledger semantics.
+  - id: tiers-not-total-order
+    statement: Strength is a tier, not a total order. weakest([invoiced,
+      measured]) MUST NOT imply that one outranks the other.
+qualifiers:
+  - id: proxy_for
+    description: The value measures a different quantity than the one being
+      reasoned about. It does not weaken the measurement; it weakens the
+      inference.
+  - id: observed_at
+    description: When a measurement was taken. Age and sample size are not
+      basis. A value may be measured and still be a single noisy sample.
+decision_grades:
+  - id: evidenced
+    when: Every load-bearing value resolves to the evidenced tier.
+  - id: projected
+    when: The weakest resolved tier is projected.
+  - id: indicative
+    when: The weakest resolved tier is judgement (estimated or assumed).
+  - id: insufficient
+    when: At least one load-bearing value is unknown.
+note: >
+  EvidenceBasis is how a quantity was obtained. It is not the
+  intended/declared/applied/observed/assessed state qualifier (OQ-3). Those
+  name which world a claim is about; this names how a number in that world
+  was produced.