coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Compare commits

base: coulomb:f2d216af53e70482793f14e735095c8a54978cf4
Branches Tags
coulomb:main
..
compare: coulomb:f2aba919f55893ebfe21bc0eda2347cf4fb8ae6a
Branches Tags
coulomb:main

No commits in common. "f2d216af53e70482793f14e735095c8a54978cf4" and "f2aba919f55893ebfe21bc0eda2347cf4fb8ae6a" have entirely different histories.
f2d216af53 ... f2aba919f5

30 changed files with 124 additions and 913 deletions
Download patch file Download diff file Expand all files Collapse all files

54
CHANGELOG.md
View file

@ -15,60 +15,6 @@ semantics.
---
## 0.4.0 — 2026-08-15
### Changed — Joinable consumer proof counts for ITC-CAP promotion
**Change.** ITC-CAP §10.3 no longer requires a canon Profile as the only
form of "a real capability requirement set with evidence." A consumer
record that validates against the live catalog and is cited from
`feedback/` is a proof. Operational facts stay in the consumer repo; the
join is the capability id.
**Met by** resource-control `data/capability/platform-audit-storage.json`
(commit `13c2b82`), cited in
`feedback/2026-08-15-resource-control-cap-restatement.md`. Requirement
`data.backup` D5 is `below_requirement` at provision D4; all four backup
hooks are measured. ITC-WP-0014 T11 done; T04 (small-saas illustration)
no longer blocks T07.
**Rationale.** A fictional in-repo example is a weaker proof than a
joinable provision that already fails or passes against this catalog.
**Breaking:** no.
### Added — EvidenceBasis (ITC-GOV), required on CapabilityConsumption
**Change.** ITC-GOV gains `EvidenceBasis`: a closed vocabulary for how a
quantity was obtained, in **tiers** rather than a total order
(`evidenced`: invoiced / measured / quoted are peers; then `projected`;
then `judgement`: estimated / assumed; then `unknown`). A derived value
resolves to the weakest *tier* among its inputs. Unknown-is-not-zero.
Optional `proxy_for` / `observed_at`. Decision grades (`evidenced` /
`projected` / `indicative` / `insufficient`). Catalog:
`infospace/models/governance/evidence-basis.yaml`. ITC-CAP 0.3.0 imports
it; CAP-R10 requires `basis` on every consumption row.
**Rationale.** Native units without a basis still let an assumed hour and
a measured gigabyte sit in one list as the same kind of knowledge. The
consumer's first application graded a €29.14/month provider comparison
`indicative`. A private scale would diverge the moment a second
repository reports provision economics — the same argument accepted for
class `H`.
**Ownership.** ITC-GOV Evidence, not a CAP-only dialect. `invoiced` names
a fin-hub booked fact; this canon does not originate booked costs. Not
the OQ-3 state qualifier.
**Breaking:** no capability id changed. New required field on consumption
records of the still-proposed capability model.
**Records.** `demand/EvidenceBasis.md`; `ITC-WP-0015` finished.
**Validation.** `make validate` 0 errors / 0 warnings; `make test` 22 passed.
---
## 0.3.0 — 2026-08-15
### Changed — Capability provision economics (requirement targets, native-unit consumption, class `H`)

8
canon.yaml
View file

@ -1,7 +1,7 @@
repository: info-tech-canon
title: InfoTechCanon
status: service-baseline
version: 0.4.0
version: 0.3.0
description: >
An evolving, markdown-first canon for building interoperable, adaptable,
and extensible information-processing systems.
@ -93,7 +93,7 @@ models:
title: InfoTechCanonCapabilityModel
path: infospace/models/capability/InfoTechCanonCapabilityModel.md
status: proposed
version: 0.3.0
version: 0.2.0
catalog: infospace/models/capability/capabilities.yaml
provenance:
assimilation: assimilation/it-capability-canon
@ -149,7 +149,6 @@ workplans:
- ITC-WP-0012
- ITC-WP-0013
- ITC-WP-0014
- ITC-WP-0015
feedback:
path: feedback/
@ -181,4 +180,5 @@ next_actions:
- implement ITC-WP-0003 validation and generated views
- implement ITC-WP-0004 small-saas profile proof
- explore ITC-WP-0006 PURPOSES model extension
- publish ITC-WP-0014 T02 capability.schema.yaml encoding ITC-CAP 0.3.0 (next ITC-CAP promotion gate; §10.3 met by resource-control join)
- publish ITC-WP-0014 T02 capability.schema.yaml encoding ITC-CAP 0.2.0 (next ITC-CAP promotion gate)
- accept resource-control restatement of the backup provision against ITC-CAP 0.2.0 (demand criterion 6 / promotion requirement 3)

192
demand/EvidenceBasis.md
View file

@ -1,192 +0,0 @@
# 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.34–11.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.

120
demand/ProvisionRelationships.md
View file

@ -1,120 +0,0 @@
# Demand: Provision-to-provision relationships — which provision satisfies a dependency
**Status:** inbound demand (un-reviewed)
**Date:** 2026-08-15
**Source:** resource-control (consumer), domain `financials`
**Proposed owner:** `ITC-CAP` (§4.7 CapabilityProvision, §7 Relationships)
**Requested by:** info-tech-canon, in reply to the ITC-CAP restatement, 2026-08-15
**Consumer evidence:** `resource-control/data/capability/platform-audit-storage.json`
**Proposed workplan:** `ITC-WP-0014` follow-on
---
## Demand signal
`ITC-CAP` §7 declares relationships at two levels:
- capability to capability — `depends_on`, `may_use`, `composes`;
- landscape or consumer to capability — `requires`, `provides`, `implements`,
`consumes`.
There is no relationship **between provisions**. The catalog can say that
`data.backup` `depends_on` `data.object`, but a provision cannot say *which
provision of `data.object` satisfies that dependency for it*.
That matters because the dependency is where the operational and economic facts
live. `data.backup depends_on data.object` is a statement about abilities.
"This backup provision depends on the Scaleway bucket in nl-ams, and would be a
different risk and a different cost against a different one" is a statement
about the world, and it is the one a consumer needs.
## How the gap surfaced
info-tech-canon found it while reviewing the consumer's restatement, and named
it precisely:
> The `P` row for credential custody is the wrong kind. `P` is purchased
> platform. What you needed is a provision naming that it uses
> `security.secrets` / depends on another provision. `depends_on_provision` is
> the right idea for the object-store layering; stuffing secrets into
> `consumes:P` is the leftover.
That is an accurate diagnosis of a consumer error. The backup provision uses
`security.secrets` — an OpenBao `ClusterSecretStore` and a synced
`ExternalSecret` — and the consumer recorded it as one unit of class `P`
consumption. Nothing is purchased there. Using another capability is not
consuming platform capacity, and the record said it was because the model
offered no other place to put it.
The consumer has removed that row. The relationship is currently held in a field
marked explicitly as **not canon**, pending this demand.
## Why it will recur
The mis-recording is the predictable result of the gap, not a one-off slip. Any
provision that uses another capability without buying capacity — secrets,
scheduling, observability, identity — has the same problem, and `consumes` is
the only structured list available. Left unaddressed, `P` slowly becomes a
dumping ground for "depends on something", and the class that finding C just
narrowed to purchased platform services widens again by usage.
---
## Proposed shape
A provision may declare which provisions it relies on:
```yaml
provision:
provider: backup.barman.prod
capability: data.backup
uses_provisions:
- capability: data.object
provider: object.scaleway.nl-ams
relation: depends_on
- capability: security.secrets
provider: openbao.reef-railiance
relation: uses
```
- `relation` reuses the existing capability-to-capability vocabulary —
`depends_on` and `may_use` (or `uses` as its provision-level spelling). No new
relationship semantics are introduced.
- A `depends_on` entry SHOULD correspond to a `depends_on` declared between the
two capabilities in the catalog; a `may_use`/`uses` entry SHOULD correspond to
a declared `may_use`. This makes the provision graph checkable against the
capability graph rather than free-form.
- Naming the provider makes maturity traversable: a provision cannot honestly
claim reliability above that of a provision it depends on, which is a rule the
canon may or may not want to state.
## What it is not
It is not consumption. `consumes` records resource classes drawn in native
units; `uses_provisions` records which other provision supplies an ability. The
distinction is exactly the one that CAP-R8 and finding C established for classes,
applied one level up.
---
## Success criteria
1. A provision can name the provisions it depends on or uses, with a relation
drawn from the existing capability-to-capability vocabulary.
2. The provision graph is checkable against the capability graph.
3. Using another capability is expressible without a consumption row, so `P`
stays purchased platform capacity.
4. `resource-control` can drop the `proposed_extensions` marker from
`data/capability/platform-audit-storage.json` and record both the object-store
dependency and the secrets usage in canon terms.
---
## Non-goals
- Provider or service identity semantics — ITC-LAND owns those; this names them
by reference.
- A deployment or topology model.
- Automatic maturity derivation across a dependency chain. Whether a provision's
maturity is capped by its dependencies is a separate question, raised here only
because this relationship is what would make it askable.

31
feedback/2026-08-15-resource-control-cap-restatement.md
View file

@ -1,7 +1,7 @@
---
id: feedback/2026-08-15-resource-control-cap-restatement
type: consumer-feedback
status: acted-on
status: reviewed
date: "2026-08-15"
consumer: resource-control
consumer_domain: financials
@ -10,14 +10,10 @@ artifacts:
- model/capability
related_demand:
- demand/CapabilityProvisionEconomics.md
- demand/EvidenceBasis.md
related_workplan:
- ITC-WP-0014
- ITC-WP-0015
spawned_demand:
- demand/EvidenceBasis.md
spawned_workplan:
- ITC-WP-0015
spawned_demand: []
spawned_workplan: []
---
# Feedback: ITC-CAP 0.2.0 restatement of platform-audit-storage
@ -110,11 +106,16 @@ None.
## Steward notes
- Status `acted-on`. Demand criterion 6 is met in the consumer repo.
ITC-CAP §10.3 was revised in canon 0.4.0: this record is the joinable
promotion proof (ITC-WP-0014 T11). Operational facts stay in
resource-control.
- Evidence-basis accepted as `demand/EvidenceBasis.md` and published as
ITC-GOV `EvidenceBasis` / CAP-R10 (ITC-WP-0015, canon 0.4.0).
- Provision-to-provision dependency remains a note, not a field. Do not
invent it until a demand or T02 needs it.
- Status `reviewed`. Demand criterion 6 is met *in the consumer repo*.
ITC-CAP §10 promotion requirement 3 still asks for a *canon Profile*.
This record is stronger evidence than a worked example and should count
toward promotion; whether that means revising §10.3 or adding a thin
in-repo example that cites the join (not the operational facts) is an
open steward decision.
- Do not copy `platform-audit-storage.json` into this repository. The
catalog stays here; the provisioned facts stay there; the join is the id.
- Evidence-basis: do not adopt from this report alone. Invite the demand
with the closed vocabulary and propagation rule, and decide ownership
(GOV Evidence vs CAP-only) when it arrives.
- Provision dependency: note as pressure on ITC-CAP / T02 schema. Do not
invent the field until a demand or T02 needs it.

5
feedback/index.yaml
View file

@ -47,9 +47,8 @@ reports:
date: "2026-08-15"
consumer: resource-control
consumer_domain: financials
status: acted-on
status: reviewed
canon_version: "0.3.0"
spawned_canon_version: "0.4.0"
artifacts:
- model/capability
hits:
@ -71,7 +70,5 @@ reports:
drop_candidates: []
related_demand:
- demand/CapabilityProvisionEconomics.md
- demand/EvidenceBasis.md
related_workplan:
- ITC-WP-0014
- ITC-WP-0015

29
infospace/agent/briefs/catalog-evidence-basis.md
View file

@ -1,29 +0,0 @@
---
id: agent-brief/catalog-evidence-basis
artifact_id: catalog/evidence-basis
source_path: models/governance/evidence-basis.yaml
source_kind: concept-catalog
generated: true
---
<!-- GENERATED by info_tech_canon; do not edit by hand. -->
# Agent Brief: InfoTechCanon Evidence Basis Catalog
- Artifact ID: `catalog/evidence-basis`
- Kind: `concept-catalog`
- Canonical path: `models/governance/evidence-basis.yaml`
- Full source: `models/governance/evidence-basis.yaml`
- Summary: Structured candidate concept catalog: InfoTechCanon Evidence Basis Catalog.
## Retrieval Hints
No imports or anchors recorded.
## Owned Concepts
- `InfoTechCanon Evidence Basis Catalog`
## Related Distinctions
No common distinction is anchored directly on this artifact.

1
infospace/agent/briefs/model-capability.md
View file

@ -19,7 +19,6 @@ generated: true
## Retrieval Hints
Imports and anchors:
- `catalog/evidence-basis`
- `kernel/itc-core`
- `model/governance`
- `model/landscape`

4
infospace/agent/global-agent-brief.md
View file

@ -5,8 +5,8 @@
This brief summarizes the current canon service surface for agents.
- Infospace slug: `canon`
- Artifact count: 66
- Retrieval index items: 66
- Artifact count: 65
- Retrieval index items: 65
- Primary confidence command: `make validate`
- Refresh generated indexes and views with: `make index`
- Refresh agent briefs and interface templates with: `make agent-briefs`

25
infospace/agent/retrieval-index.json
View file

@ -43,7 +43,7 @@
}
],
"infospace": "canon",
"item_count": 66,
"item_count": 65,
"items": [
{
"canonical_path": "assimilation/it-capability-canon/ASSIMILATION.md",
@ -267,20 +267,6 @@
"title": "InfoTechCanon Capability Catalog",
"warnings": []
},
{
"canonical_path": "models/governance/evidence-basis.yaml",
"id": "catalog/evidence-basis",
"imports": [],
"kind": "concept-catalog",
"owned_concepts": [
"InfoTechCanon Evidence Basis Catalog"
],
"relationships": [],
"source_path": "demand/EvidenceBasis.md",
"summary": "Structured candidate concept catalog: InfoTechCanon Evidence Basis Catalog.",
"title": "InfoTechCanon Evidence Basis Catalog",
"warnings": []
},
{
"canonical_path": "evaluations/repo-scoping/canon-benefit-analysis.yaml",
"id": "comparison/repo-scoping/canon-benefit-analysis",
@ -1102,7 +1088,6 @@
"canonical_path": "models/capability/InfoTechCanonCapabilityModel.md",
"id": "model/capability",
"imports": [
"catalog/evidence-basis",
"kernel/itc-core",
"model/governance",
"model/landscape",
@ -1147,10 +1132,6 @@
"target": "model/observability",
"type": "uses"
},
{
"target": "catalog/evidence-basis",
"type": "uses"
},
{
"target": "capability-catalog/itc-cap",
"type": "introduces"
@ -1231,10 +1212,6 @@
{
"target": "kernel/itc-core",
"type": "conforms_to"
},
{
"target": "catalog/evidence-basis",
"type": "introduces"
}
],
"source_path": "seeds/InfoTechCanonGovernanceModel_RC1_seed.md",

14
infospace/agent/retrieval-index.md
View file

@ -4,7 +4,7 @@
Schema: `info-tech-canon.retrieval-index.v1`
Infospace: `canon`
Items: **66**
Items: **65**
## Common Distinctions
@ -85,16 +85,6 @@ Items: **66**
- Imports and anchors: none
- Owned concepts: `InfoTechCanon Capability Catalog`
### InfoTechCanon Evidence Basis Catalog
- ID: `catalog/evidence-basis`
- Kind: `concept-catalog`
- Canonical path: `models/governance/evidence-basis.yaml`
- Source path: `demand/EvidenceBasis.md`
- Summary: Structured candidate concept catalog: InfoTechCanon Evidence Basis Catalog.
- Imports and anchors: none
- Owned concepts: `InfoTechCanon Evidence Basis Catalog`
### Repo Scoping Canon Benefit Analysis
- ID: `comparison/repo-scoping/canon-benefit-analysis`
@ -312,7 +302,7 @@ Items: **66**
- Canonical path: `models/capability/InfoTechCanonCapabilityModel.md`
- Source path: `infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md`
- Summary: Domain model used by canon profiles and standards: InfoTechCanon Capability Model.
- Imports and anchors: `catalog/evidence-basis`, `kernel/itc-core`, `model/governance`, `model/landscape`, `model/observability`, `model/purpose-demand-extension`
- Imports and anchors: `kernel/itc-core`, `model/governance`, `model/landscape`, `model/observability`, `model/purpose-demand-extension`
- Owned concepts: `Capability`, `CapabilityConsumption`, `CapabilityContract`, `CapabilityDomain`, `CapabilityEvidenceHook`, `CapabilityInclusionRule`, `CapabilityMaturityLevel`, `CapabilityProfile`, `CapabilityProvider`, `CapabilityProvision`, `CapabilityQualityDimension`, `CapabilityRequirement`, `CapabilityResourceClass`, `InfoTechCanon Capability Model`
### InfoTechCanon Data Model

18
infospace/agent/retrieval-index.yaml
View file

@ -1,6 +1,6 @@
schema: info-tech-canon.retrieval-index.v1
infospace: canon
item_count: 66
item_count: 65
items:
- id: assimilation/it-capability-canon
kind: assimilation
@ -144,17 +144,6 @@ items:
imports: []
relationships: []
warnings: []
- id: catalog/evidence-basis
kind: concept-catalog
title: InfoTechCanon Evidence Basis Catalog
canonical_path: models/governance/evidence-basis.yaml
source_path: demand/EvidenceBasis.md
summary: 'Structured candidate concept catalog: InfoTechCanon Evidence Basis Catalog.'
owned_concepts:
- InfoTechCanon Evidence Basis Catalog
imports: []
relationships: []
warnings: []
- id: comparison/repo-scoping/canon-benefit-analysis
kind: benefit-analysis
title: Repo Scoping Canon Benefit Analysis
@ -698,7 +687,6 @@ items:
- CapabilityResourceClass
- InfoTechCanon Capability Model
imports:
- catalog/evidence-basis
- kernel/itc-core
- model/governance
- model/landscape
@ -715,8 +703,6 @@ items:
target: model/purpose-demand-extension
- type: uses
target: model/observability
- type: uses
target: catalog/evidence-basis
- type: introduces
target: capability-catalog/itc-cap
- type: derived_from
@ -772,8 +758,6 @@ items:
relationships:
- type: conforms_to
target: kernel/itc-core
- type: introduces
target: catalog/evidence-basis
warnings: []
- id: model/information-space
kind: model

13
infospace/artifacts/index.yaml
View file

@ -89,8 +89,6 @@ artifacts:
relationships:
- type: conforms_to
target: kernel/itc-core
- type: introduces
target: catalog/evidence-basis
- id: model/purpose-demand-extension
path: models/governance/InfoTechCanonPurposeDemandExtension.md
kind: model-extension
@ -129,21 +127,10 @@ artifacts:
target: model/purpose-demand-extension
- type: uses
target: model/observability
- type: uses
target: catalog/evidence-basis
- type: introduces
target: capability-catalog/itc-cap
- type: derived_from
target: assimilation/it-capability-canon
- id: catalog/evidence-basis
path: models/governance/evidence-basis.yaml
kind: concept-catalog
title: InfoTechCanon Evidence Basis Catalog
provenance:
source_path: demand/EvidenceBasis.md
placement: adapted
placement_workplan: ITC-WP-0015
relationships: []
- id: capability-catalog/itc-cap
path: models/capability/capabilities.yaml
kind: capability-catalog

5
infospace/indexes/artifact-tree.yaml
View file

@ -1,5 +1,5 @@
root: infospace
file_count: 176
file_count: 175
files:
- path: README.md
directory: .
@ -358,9 +358,6 @@ files:
- path: models/governance/InfoTechCanonPurposeDemandExtension.md
directory: models/governance
name: InfoTechCanonPurposeDemandExtension.md
- path: models/governance/evidence-basis.yaml
directory: models/governance
name: evidence-basis.yaml
- path: models/information-space/InfoTechCanonInformationSpaceModel.md
directory: models/information-space
name: InfoTechCanonInformationSpaceModel.md

6
infospace/indexes/concept-ownership.yaml
View file

@ -1,4 +1,4 @@
concept_count: 108
concept_count: 107
concepts:
- concept: "Assimilation \u2014 IT Capability Canon (ITCC) v0.1"
owner: assimilation/it-capability-canon
@ -28,10 +28,6 @@ concepts:
owner: capability-catalog/itc-cap
path: models/capability/capabilities.yaml
source: artifact_title
- concept: InfoTechCanon Evidence Basis Catalog
owner: catalog/evidence-basis
path: models/governance/evidence-basis.yaml
source: artifact_title
- concept: Repo Scoping Canon Benefit Analysis
owner: comparison/repo-scoping/canon-benefit-analysis
path: evaluations/repo-scoping/canon-benefit-analysis.yaml

7
infospace/indexes/import-matrix.yaml
View file

@ -6,7 +6,6 @@ artifacts:
- benchmark/caring/kubernetes-rbac/findings
- benchmark/caring/kubernetes-rbac/native-concepts
- capability-catalog/itc-cap
- catalog/evidence-basis
- comparison/repo-scoping/canon-benefit-analysis
- comparison/repo-scoping/consumer-workplan-brief
- comparison/repo-scoping/extension-candidates
@ -134,8 +133,6 @@ rows:
- maps
- artifact: capability-catalog/itc-cap
targets: {}
- artifact: catalog/evidence-basis
targets: {}
- artifact: comparison/repo-scoping/canon-benefit-analysis
targets:
comparison/repo-scoping/report:
@ -400,8 +397,6 @@ rows:
- derived_from
capability-catalog/itc-cap:
- introduces
catalog/evidence-basis:
- uses
kernel/itc-core:
- conforms_to
model/governance:
@ -426,8 +421,6 @@ rows:
- uses
- artifact: model/governance
targets:
catalog/evidence-basis:
- introduces
kernel/itc-core:
- conforms_to
- artifact: model/information-space

48
infospace/models/capability/InfoTechCanonCapabilityModel.md
View file

@ -7,7 +7,7 @@ standard_family: InfoTechCanon
repository_context: info-tech-canon
recommended_path: models/capability/InfoTechCanonCapabilityModel.md
status: proposed
version: 0.3.0
version: 0.2.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.3.0
**Version:** 0.2.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,30 +253,21 @@ 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`).
@ -383,10 +374,6 @@ 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
@ -430,13 +417,6 @@ 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
@ -519,7 +499,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, 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-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-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. |
@ -538,22 +518,8 @@ 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 **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`.
3. at least one canon Profile expressing a real capability requirement set with
evidence;
4. formal mapping artifacts under `infospace/mappings/` for each anchor.
Tracked in `ITC-WP-0014`.
@ -578,7 +544,3 @@ 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.

4
infospace/models/capability/capabilities.yaml
View file

@ -12,9 +12,9 @@ canon:
name: InfoTechCanon Capability Model — Capability Catalog
short_name: ITC-CAP
artifact_id: model/capability
version: 0.3.0
version: 0.2.0
status: proposed
canon_version: 0.4.0
canon_version: 0.3.0
purpose: Canonical, implementation-independent catalog of the abilities an information system may require
or provide.
normative_document: models/capability/InfoTechCanonCapabilityModel.md

47
infospace/models/governance/InfoTechCanonGovernanceModel.md
View file

@ -1066,53 +1066,6 @@ 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

110
infospace/models/governance/evidence-basis.yaml
View file

@ -1,110 +0,0 @@
# 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.

6
infospace/validation/latest.json
View file

@ -1,14 +1,14 @@
{
"details": {
"artifact_count": 66,
"relationship_count": 288
"artifact_count": 65,
"relationship_count": 286
},
"errors": [],
"metrics": {
"coherence_components": 1.0,
"consistency_cycles": 0.0,
"coverage_ratio": 1.0,
"granularity_entropy": 4.459014704982469,
"granularity_entropy": 4.443367176892838,
"redundancy_ratio": 0.0
},
"ok": true,

3
infospace/views/by-concept.md
View file

@ -2,7 +2,7 @@
# By Concept
Concept count: **108**
Concept count: **107**
| Concept | Owner | Source |
| --- | --- | --- |
@ -13,7 +13,6 @@ Concept count: **108**
| Kubernetes RBAC Benchmark Findings And Canon Pressure | `benchmark/caring/kubernetes-rbac/findings` | `artifact_title` |
| Kubernetes RBAC Native Concept Map | `benchmark/caring/kubernetes-rbac/native-concepts` | `artifact_title` |
| InfoTechCanon Capability Catalog | `capability-catalog/itc-cap` | `artifact_title` |
| InfoTechCanon Evidence Basis Catalog | `catalog/evidence-basis` | `artifact_title` |
| Repo Scoping Canon Benefit Analysis | `comparison/repo-scoping/canon-benefit-analysis` | `artifact_title` |
| Repo Scoping Consumer Workplan Brief | `comparison/repo-scoping/consumer-workplan-brief` | `artifact_title` |
| Repo Scoping Canon Extension Candidates | `comparison/repo-scoping/extension-candidates` | `artifact_title` |

5
infospace/views/by-mapping-target.md
View file

@ -19,11 +19,6 @@
- `model/capability` via `introduces`
## `catalog/evidence-basis`
- `model/capability` via `uses`
- `model/governance` via `introduces`
## `comparison/repo-scoping/report`
- `comparison/repo-scoping/canon-benefit-analysis` via `part_of`

135
infospace/views/import-matrix.md
View file

@ -2,71 +2,70 @@
# Import Matrix
| Artifact | `assimilation/it-capability-canon` | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `capability-catalog/itc-cap` | `catalog/evidence-basis` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/capability` | `model/data` | `model/devsecops` | `model/governance` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `practice/intake-and-assimilation` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/repository-layout` | `standard/tagging` |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| `assimilation/it-capability-canon` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `benchmark/caring/kubernetes-rbac` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `stress_tests` | | | `stress_tests` | `stress_tests` | | | `stress_tests` | `stress_tests` | | | `stress_tests` | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | `uses` |
| `benchmark/caring/kubernetes-rbac/access-descriptors` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | |
| `benchmark/caring/kubernetes-rbac/caring-mapping` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | `maps` | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | |
| `benchmark/caring/kubernetes-rbac/findings` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | | | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | |
| `benchmark/caring/kubernetes-rbac/native-concepts` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | |
| `capability-catalog/itc-cap` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `catalog/evidence-basis` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/canon-benefit-analysis` | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | `maps` | `maps` | | | | | `maps` | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` |
| `comparison/repo-scoping/consumer-workplan-brief` | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/extension-candidates` | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | `proposes` | `proposes` | | | | | `proposes` | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/frame` | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/report` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | | | | `compares` | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | |
| `concept-catalog/purpose-demand` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` |
| `conformance/railiance-fabric/consumer-workplan-brief` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/entity-edge-capture-criteria` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/mapping-expectations` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | `maps` | `maps` | `maps` | | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/visualization-examples` | | | | | | | | | | | | | | | `part_of` | | `illustrates` | `illustrates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | `uses` | | | | | `uses` | `uses` | `uses` | `uses` | | | `evaluates` | | | | | | | | | | | | | | | | | | | | `uses` | | |
| `evaluation/user-engine/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine/interface-card-expectations` | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | |
| `evaluation/user-engine/questions` | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | `uses` | | `uses` | | `uses` | | | | | `uses` | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine/small-saas-alignment` | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | `uses` | | | | `uses` | | | | | `uses` | | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | |
| `example/consumer-purpose-portfolio` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `illustrates` | | | `illustrates` | | `uses` | | | | | | | | | | | | | | | | | | | | | | |
| `kernel/itc-core` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `kernel/itc-kernel-map` | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | `maps` | | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | `maps` | | `maps` |
| `mapping/purpose-demand-governance-candidates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | `maps` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/access-control` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/capability` | `derived_from` | | | | | | `introduces` | `uses` | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | `uses` | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/data` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/devsecops` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/governance` | | | | | | | | `introduces` | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/information-space` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/landscape` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/network` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/observability` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/organization` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/purpose-demand-extension` | | | | | | | | | | | | | | `introduces` | | | | | | | | | | | | `conforms_to` | | | | | | | `extends` | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/security` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/task` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `pattern/intent-scope-purposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `implements` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `practice/intake-and-assimilation` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `profile/small-saas` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `requires` | | `requires` | `requires` | `requires` | | `requires` | `requires` | `requires` | `requires` | | `requires` | `requires` | | | | | | | | | | | | | | | | | | | | | | | `requires` | | `requires` |
| `review-kit/alignment` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | `uses` | | |
| `review-kit/alignment/model-selection-guide` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | | | `uses` | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | `uses` |
| `review-kit/alignment/schema` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/scorecard` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/workflow` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/workplan-template` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/control/namespace-per-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `instantiates` | | | | | | | | | | `evidenced_by` | | | | | | | | | | `uses` | | |
| `small-saas/dataset/subscription-ledger` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | `governed_by` | `owned_by` | | | | `partitioned_for` | `partitioned_for` | | | | |
| `small-saas/deployment/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | | | | | | | `instantiates` | | | | | | | `implements` | | | | | | `deploys` | | | | `separates` | `separates` | | | | |
| `small-saas/evidence/access-review-2026-05` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/incident/cross-tenant-access-attempt` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `instantiates` | | | | | | | `constrained_by` | | | `evidenced_by` | | | | | | | | | | | | |
| `small-saas/policy/tenant-isolation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | `requires` | | | `evidenced_by` | | | | | | | | | | | | |
| `small-saas/service/billing-portal` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | `part_of` | | `owned_by` | | | | | | |
| `small-saas/system/billing-system` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | `serves` | `serves` | | | | |
| `small-saas/task/onboard-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `instantiates` | | | | | | | | | | | | `governed_by` | | | | `owned_by` | `changes` | | | | | |
| `small-saas/team/platform` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/tenant/acme` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | `isolated_by` | | | | | | | | | | | | `represented_by` | | | |
| `small-saas/tenant/globex` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | `isolated_by` | | | | | | | | | | | | | | | |
| `small-saas/user/ada-admin` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | `access_evidenced_by` | | `has_access_under` | | | | `member_of` | | | | | | |
| `standard/caring` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `imports` | | `imports` | `imports` | `imports` | | | `imports` | `imports` | `imports` | | `imports` | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | `imports` |
| `standard/repository-layout` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `imports` | `imports` | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `standard/tagging` | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | |
| Artifact | `assimilation/it-capability-canon` | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `capability-catalog/itc-cap` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/capability` | `model/data` | `model/devsecops` | `model/governance` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `practice/intake-and-assimilation` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/repository-layout` | `standard/tagging` |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| `assimilation/it-capability-canon` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `benchmark/caring/kubernetes-rbac` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `stress_tests` | | | `stress_tests` | `stress_tests` | | | `stress_tests` | `stress_tests` | | | `stress_tests` | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | `uses` |
| `benchmark/caring/kubernetes-rbac/access-descriptors` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | |
| `benchmark/caring/kubernetes-rbac/caring-mapping` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | `maps` | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | |
| `benchmark/caring/kubernetes-rbac/findings` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | | | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | |
| `benchmark/caring/kubernetes-rbac/native-concepts` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | |
| `capability-catalog/itc-cap` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/canon-benefit-analysis` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | `maps` | `maps` | | | | | `maps` | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` |
| `comparison/repo-scoping/consumer-workplan-brief` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/extension-candidates` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | `proposes` | `proposes` | | | | | `proposes` | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/frame` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/report` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | | | | `compares` | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | |
| `concept-catalog/purpose-demand` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` |
| `conformance/railiance-fabric/consumer-workplan-brief` | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/entity-edge-capture-criteria` | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/mapping-expectations` | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | `maps` | `maps` | `maps` | | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/visualization-examples` | | | | | | | | | | | | | | `part_of` | | `illustrates` | `illustrates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | `uses` | | | | | `uses` | `uses` | `uses` | `uses` | | | `evaluates` | | | | | | | | | | | | | | | | | | | | `uses` | | |
| `evaluation/user-engine/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine/interface-card-expectations` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | |
| `evaluation/user-engine/questions` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | `uses` | | `uses` | | `uses` | | | | | `uses` | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine/small-saas-alignment` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | `uses` | | | | `uses` | | | | | `uses` | | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | |
| `example/consumer-purpose-portfolio` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `illustrates` | | | `illustrates` | | `uses` | | | | | | | | | | | | | | | | | | | | | | |
| `kernel/itc-core` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `kernel/itc-kernel-map` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | `maps` | | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | `maps` | | `maps` |
| `mapping/purpose-demand-governance-candidates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | `maps` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/access-control` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/capability` | `derived_from` | | | | | | `introduces` | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | `uses` | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/data` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/devsecops` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/governance` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/information-space` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/landscape` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/network` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/observability` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/organization` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/purpose-demand-extension` | | | | | | | | | | | | | `introduces` | | | | | | | | | | | | `conforms_to` | | | | | | | `extends` | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/security` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/task` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `pattern/intent-scope-purposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `implements` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `practice/intake-and-assimilation` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `profile/small-saas` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `requires` | | `requires` | `requires` | `requires` | | `requires` | `requires` | `requires` | `requires` | | `requires` | `requires` | | | | | | | | | | | | | | | | | | | | | | | `requires` | | `requires` |
| `review-kit/alignment` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | `uses` | | |
| `review-kit/alignment/model-selection-guide` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | | | `uses` | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | `uses` |
| `review-kit/alignment/schema` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/scorecard` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/workflow` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/workplan-template` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/control/namespace-per-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `instantiates` | | | | | | | | | | `evidenced_by` | | | | | | | | | | `uses` | | |
| `small-saas/dataset/subscription-ledger` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | `governed_by` | `owned_by` | | | | `partitioned_for` | `partitioned_for` | | | | |
| `small-saas/deployment/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | | | | | | | `instantiates` | | | | | | | `implements` | | | | | | `deploys` | | | | `separates` | `separates` | | | | |
| `small-saas/evidence/access-review-2026-05` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/incident/cross-tenant-access-attempt` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `instantiates` | | | | | | | `constrained_by` | | | `evidenced_by` | | | | | | | | | | | | |
| `small-saas/policy/tenant-isolation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | `requires` | | | `evidenced_by` | | | | | | | | | | | | |
| `small-saas/service/billing-portal` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | `part_of` | | `owned_by` | | | | | | |
| `small-saas/system/billing-system` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | `serves` | `serves` | | | | |
| `small-saas/task/onboard-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `instantiates` | | | | | | | | | | | | `governed_by` | | | | `owned_by` | `changes` | | | | | |
| `small-saas/team/platform` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/tenant/acme` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | `isolated_by` | | | | | | | | | | | | `represented_by` | | | |
| `small-saas/tenant/globex` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | `isolated_by` | | | | | | | | | | | | | | | |
| `small-saas/user/ada-admin` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | `access_evidenced_by` | | `has_access_under` | | | | `member_of` | | | | | | |
| `standard/caring` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `imports` | | `imports` | `imports` | `imports` | | | `imports` | `imports` | `imports` | | `imports` | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | `imports` |
| `standard/repository-layout` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `imports` | `imports` | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `standard/tagging` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | |

8
infospace/views/kernel-overview.md
View file

@ -3,7 +3,7 @@
# Kernel Overview
- Infospace: `canon`
- Artifacts: 66
- Artifacts: 65
## Artifact Kinds
@ -21,7 +21,7 @@
- `caring-mapping`: 1
- `comparison-frame`: 1
- `comparison-report`: 1
- `concept-catalog`: 2
- `concept-catalog`: 1
- `conformance-pack`: 1
- `consumer-workplan-brief`: 3
- `consumer-workplan-template`: 1
@ -63,7 +63,7 @@
- `implements`: 2
- `imports`: 14
- `instantiates`: 13
- `introduces`: 3
- `introduces`: 2
- `isolated_by`: 2
- `maps`: 36
- `member_of`: 1
@ -76,4 +76,4 @@
- `separates`: 2
- `serves`: 2
- `stress_tests`: 6
- `uses`: 118
- `uses`: 117

2
tests/test_cli.py
View file

@ -11,7 +11,7 @@ def test_cli_inspect_emits_json(capsys) -> None:
assert exit_code == 0
payload = json.loads(capsys.readouterr().out)
assert payload["ok"] is True
assert payload["infospace"]["artifact_count"] == 66
assert payload["infospace"]["artifact_count"] == 65
def test_cli_missing_profile_uses_structured_error(capsys) -> None:

8
tests/test_service.py
View file

@ -21,7 +21,7 @@ def test_inspect_canon_counts_artifact_kinds() -> None:
assert payload["ok"] is True
assert payload["infospace"]["slug"] == "canon"
assert payload["infospace"]["artifact_count"] == 66
assert payload["infospace"]["artifact_count"] == 65
assert payload["infospace"]["kinds"] == {
"access-descriptor-set": 1,
"alignment-review-kit": 1,
@ -37,7 +37,7 @@ def test_inspect_canon_counts_artifact_kinds() -> None:
"caring-mapping": 1,
"comparison-frame": 1,
"comparison-report": 1,
"concept-catalog": 2,
"concept-catalog": 1,
"conformance-pack": 1,
"consumer-workplan-brief": 3,
"consumer-workplan-template": 1,
@ -93,14 +93,14 @@ def test_validate_canon_passes_scaffold() -> None:
assert payload["ok"] is True
assert payload["errors"] == []
assert "warnings" in payload
assert payload["details"]["artifact_count"] == 66
assert payload["details"]["artifact_count"] == 65
def test_graph_exports_relationship_summary() -> None:
payload = artifact_graph()
assert payload["ok"] is True
assert payload["graph"]["node_count"] == 66
assert payload["graph"]["node_count"] == 65
assert payload["graph"]["edge_count"] > 15

35
workplans/ITC-WP-0014-capability-model-consolidation.md
View file

@ -70,11 +70,10 @@ state_hub_task_id: "1ed8d07a-34ee-4ad4-8e4a-03a513c14836"
Add the capability contract schema under `infospace/schemas/`, register it in
`infospace/infospace.yaml`, and validate `capabilities.yaml` against it.
Encode ITC-CAP 0.3.0: no `typical_resource_classes` on contracts; resource
classes carry `native_unit`, `supply`, and `capacity_behaviour`; consumption
rows require EvidenceBasis (CAP-R10); requirement and provision record
shapes live in the model prose until a companion requirement/provision
schema is justified. §10.3 is already met by the resource-control join.
Encode ITC-CAP 0.2.0: no `typical_resource_classes` on contracts; resource
classes carry `native_unit`, `supply`, and `capacity_behaviour`; requirement
and provision record shapes live in the model prose until a companion
requirement/provision schema is justified.
### T03 — Formal mapping artifacts for each anchor
@ -100,9 +99,8 @@ state_hub_task_id: "182e0ad5-5fb9-4d50-9576-b9f5fdff91d3"
```
Express a real `CapabilityRequirement` set with provisions and evidence in the
small-saas profile (coordinate with ITC-WP-0004). Useful in-repo illustration.
**No longer the promotion gate** — §10.3 now accepts a consumer record that
validates against the live catalog (T11).
small-saas profile (coordinate with ITC-WP-0004). This is the practical proof
required for promotion.
### T05 — Landscape and kernel-map revision
@ -138,13 +136,12 @@ source §18. Covers OQ-6.
id: ITC-WP-0014-T07
status: todo
priority: medium
depends_on: [T01, T02, T03, T11]
depends_on: [T01, T02, T03, T04]
state_hub_task_id: "455690e3-c39a-4926-a13b-a179b134b2a4"
```
Promote the model from `proposed` to `draft` or `release-candidate`, bump the
canon version, and write the `CHANGELOG.md` entry. T04 (small-saas illustration)
is no longer a promotion dependency.
canon version, and write the `CHANGELOG.md` entry.
### T08 — Finding A: move resource-class declaration off the contract
@ -190,22 +187,6 @@ supply/capacity defaults, record consumption in native units, add
**Done 2026-08-15 (canon 0.3.0 / ITC-CAP 0.2.0).** Landed here rather than as a
new workplan: no LAND or commerce owning-model change was required.
### T11 — Joinable consumer proof for §10.3
```task
id: ITC-WP-0014-T11
status: done
priority: high
```
Revise §10.3 so a consumer record that validates against the live catalog
and is cited from `feedback/` counts as the promotion proof. Record
resource-control `data/capability/platform-audit-storage.json` (commit
`13c2b82`) as that proof.
**Done 2026-08-15 (canon 0.4.0 / ITC-CAP 0.3.0).** Operational facts stay
in the consumer repo.
## Out of scope
- New domain models for `commerce.*` / `intelligence.*` (OQ-5) — the 2026-08-15

81
workplans/ITC-WP-0015-evidence-basis.md
View file

@ -1,81 +0,0 @@
---
id: ITC-WP-0015
type: workplan
title: "Evidence Basis catalog (Governance extension)"
domain: infotech
topic_slug: canon
repo: info-tech-canon
status: finished
priority: high
created: "2026-08-15"
updated: "2026-08-15"
owner: grok
depends_on_workplans:
- ITC-WP-0014
spec_refs:
- demand/EvidenceBasis.md
- infospace/models/governance/InfoTechCanonGovernanceModel.md
- infospace/models/governance/evidence-basis.yaml
- infospace/models/capability/InfoTechCanonCapabilityModel.md
---
# ITC-WP-0015 — Evidence Basis
## Goal
Give quantities a closed, ordered scale for *how they were obtained*, owned
by ITC-GOV and imported by ITC-CAP consumption, so assumed hours and
measured gigabytes cannot sit in one list as if they were the same kind of
knowledge.
## Intent
resource-control published the vocabulary and showed it grading their own
provider comparison `indicative`. They asked whether we wanted it as a
demand. We do. Ownership is GOV Evidence, not a CAP-only dialect, because
the same scale is needed on actuals and thresholds.
## Tasks
### T01 — Demand intake
```task
id: ITC-WP-0015-T01
status: done
priority: high
```
Steward-file `demand/EvidenceBasis.md` from the consumer's published
`docs/evidence-basis.md` and `tools/basis.py`. Do not copy the
implementation.
### T02 — Catalog and GOV section
```task
id: ITC-WP-0015-T02
status: done
priority: high
depends_on: [T01]
```
Add `infospace/models/governance/evidence-basis.yaml` as the closed
vocabulary and §11.34a `EvidenceBasis` to the Governance Model.
### T03 — Import on CapabilityConsumption
```task
id: ITC-WP-0015-T03
status: done
priority: high
depends_on: [T02]
```
CAP-R10: a consumption row MUST declare `basis`. Unknown carries no
quantity. ITC-CAP 0.3.0 / canon 0.4.0.
## Out of scope
- Ledger or invoiced-fact origination (fin-hub).
- Canon-wide state qualifiers (OQ-3).
- Retrofitting resource-control actuals and thresholds — that is their work
against this catalog.

13
workplans/index.yaml
View file

@ -217,16 +217,3 @@ workplans:
produces:
- feedback/
- first consumer utility report (resource-control / ITC-CAP)
- id: ITC-WP-0015
title: Evidence Basis catalog (Governance extension)
status: finished
priority: high
path: workplans/ITC-WP-0015-evidence-basis.md
depends_on:
- ITC-WP-0014
produces:
- demand/EvidenceBasis.md
- models/governance/evidence-basis.yaml
- EvidenceBasis section in ITC-GOV
- CAP-R10 on CapabilityConsumption