info-tech-canon/demand/EvidenceBasis.md
tegwick f2d216af53
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
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

192 lines
8.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Demand: Evidence Basis — how a quantity was obtained, and how far a conclusion may be trusted
**Status:** accepted (canon 0.4.0)
**Date:** 2026-08-15
**Source:** resource-control (consumer), domain `financials`
**Owner:** **ITC-GOV** (Evidence), imported by `ITC-CAP` `CapabilityConsumption` (CAP-R10)
**Requested by:** info-tech-canon, in reply to the ITC-CAP restatement, 2026-08-15
**Consumer implementation:** `resource-control/tools/basis.py`, `docs/evidence-basis.md`
**Workplan:** `ITC-WP-0015`
**Catalog:** `infospace/models/governance/evidence-basis.yaml`
---
## Demand signal
ITC-GOV §11.34 defines **Evidence** as "information used to support a claim",
with examples that are all *artifact kinds*: a log extract, a scan result, a
test result, a deployment record. §11.35 defines an **Assertion** as a claim
that something is true, supported by evidence.
Nothing in the canon says **how a quantity was obtained**, and therefore nothing
bounds how far a conclusion computed from it may be trusted.
That is a different question from which artifact supports a claim. An artifact
can be impeccable while the number inside it is a guess. A consumer reading two
numbers of the same shape — `7.35` and `60.00` — cannot tell that one is a
published price and the other is an assumed hour count multiplied by an assumed
rate, and the canon currently gives it no way to say so.
## Why this cannot stay private to one consumer
`resource-control` has implemented and is running this. We are filing rather
than keeping it because the same argument info-tech-canon accepted for
`CapabilityConsumption` applies unchanged: a private vocabulary diverges the
moment a second repository reports evidence-bearing quantities.
It is already wanted in three places on the consumer side alone — capability
consumption rows, monthly actual observations, and threshold evaluations. That
breadth is also why the concept should **not** live in ITC-CAP: it is not about
capabilities. It is about quantities, wherever they occur.
---
## Proposed concepts
### `EvidenceBasis`
A closed, ordered vocabulary naming how a single quantity was obtained.
| Basis | Meaning |
|---|---|
| `invoiced` | Taken from an authoritative financial record |
| `measured` | Directly observed from the authoritative system |
| `quoted` | Stated by a provider or counterparty in a citable source |
| `derived` | Computed from other values by a stated rule |
| `projected` | Interpolated between, or extrapolated beyond, observations |
| `estimated` | Human judgement, neither observed nor computed |
| `assumed` | A modelling constant chosen by the author |
| `unknown` | No value exists |
`invoiced`, `measured`, and `quoted` are **evidenced**: they assert an observed
or contracted fact. Everything below is inference.
**On `invoiced`.** Per info-tech-canon's own instruction, this names a fin-hub
fact rather than originating one. The basis says only *where a value came from*;
it does not define booked-cost, tax, or currency semantics, which stay with the
financial authority under its own exchange contract.
**Strength is a tier, not a total order.** `invoiced` and `measured` are peers.
An invoice is authoritative for a payment and a measurement is authoritative for
a quantity; neither outranks the other outside its own domain. The consumer's
first implementation got this wrong by using a strict list order, and corrected
it — `weakest(["invoiced", "measured"])` must not imply a difference that does
not exist.
### `derived_from` and the propagation rule
> **A derived value is only as strong as the weakest value it was computed from.**
This is the rule that earns the vocabulary its place. Without it, arithmetic
launders assumptions: a two-decimal euro figure reads like a measurement when it
is an assumed hour count times an assumed rate.
A `derived` value carries `derived_from`, the values it was computed from, and
resolves to the weakest of them, recursively. Derivation is not penalised in
itself: GB computed from measured bytes resolves to `measured`.
### `unknown` carries no quantity
A value with basis `unknown` MUST NOT carry a quantity, and MUST name the gap
and the party who owns it. A value with any other basis MUST carry a quantity.
Zero means "measured and none"; unknown means "not measured". Both directions
should be enforced, because the failure mode runs both ways — a missing amount
silently read as zero, and a zero mistaken for an absence.
### `proxy_for`
An orthogonal qualifier: the value is a genuine measurement of a *different*
quantity than the one being reasoned about. It does not weaken the measurement;
it weakens the inference drawn from it. A shared-database allocation driver may
measure bytes precisely while one of those databases has never recorded a
transaction.
### `DecisionGrade`
A rollup over the values a conclusion rests on — an **Assertion** whose strength
is bounded by its weakest supporting value.
| Grade | Condition |
|---|---|
| `evidenced` | Every load-bearing value is invoiced, measured, or quoted |
| `projected` | The conclusion rests on values projected from observations |
| `indicative` | The conclusion is no stronger than an estimated or assumed value |
| `insufficient` | At least one load-bearing value is unknown |
This is the seam to existing ITC-GOV vocabulary: Evidence supports an Assertion;
a DecisionGrade states how far that support actually reaches.
---
## Worked evidence from the consumer
The mechanism was applied to the consumer's own most consequential decision —
the provider selection that produced its backup resource, a €29.14 per month
difference stated to the cent:
```
by_basis {quoted: 1, projected: 1, assumed: 2}
weakest assumed
evidenced_ratio 0.25
grade indicative
```
One of four load-bearing values is evidenced. The two labour figures — the ones
that actually inverted the provider ranking — are each `derived` from an
`assumed` hour count and an `assumed` rate, so both resolve to `assumed`.
The finding did not overturn the decision: the direction is robust under any
plausible rate. It did establish that the *magnitude* is a model output rather
than a measurement, and it identified the cheapest way to strengthen it —
record real operator hours, not refine the arithmetic.
A mechanism whose first act is to qualify its author's own headline number is
behaving correctly.
---
## Proposed placement
**Owner: ITC-GOV.** `EvidenceBasis`, `derived_from` and its propagation rule,
the unknown rule, `proxy_for`, and `DecisionGrade` sit beside Evidence,
Assertion, and Attestation in §11.3411.36. They describe the epistemic status
of information, which is ITC-GOV's ground.
**Import: ITC-CAP.** `CapabilityConsumption` gains an evidence basis per row.
It already distinguishes unknown from zero, which is the same discipline applied
to presence; basis applies it to the values that *are* present. `CAP-R8` would
be joined by a rule that a consumption row declares its basis.
**Also imports:** ITC-OBS (a measurement is `measured`; a modelled series is
`projected`), and any model carrying quantities that consumers compare.
**Avoid:** defining this only in ITC-CAP. It is not about capabilities, and
scoping it there would force a second, incompatible vocabulary the first time a
non-capability quantity needs grading.
---
## Success criteria
1. A closed basis vocabulary with tiers, not a spurious total order.
2. A stated propagation rule for derived values, computable and testable.
3. Unknown carries no quantity and names its gap and owner; zero is a
measurement.
4. `proxy_for` expressible and orthogonal to strength.
5. Decision grades defined against existing Assertion semantics.
6. `CapabilityConsumption` imports the basis without ITC-CAP owning it.
7. `resource-control` can drop its private vocabulary in favour of the canon's
without changing any recorded value.
---
## Non-goals
- Booked-cost, tax, or currency semantics. `invoiced` names a financial fact;
it does not define one.
- A confidence interval, probability, or statistical error model. Basis is
categorical provenance, not quantified uncertainty. A value may be `measured`
and still be a single noisy sample — age and sample size are separate
qualifiers and the canon should not conflate them with basis.
- A data-quality scoring or maturity scheme for datasets.
- An automated inference of basis. It is declared by the author of the value.