Add feedback/ for consumer reports on canon-concept utility

A third front door next to incoming/ and demand/: longitudinal PurposeFit
evidence, not a change request and not a canon artifact. Seeded with the
resource-control backup-cycle mapping.

README.md

@@ -97,6 +97,11 @@ consumer purposes, demand signals, purpose fit, scope pressure, and evolution
 requests so consumer demand can inform repo governance without silently changing
 producer scope.
 
+Consumer-filed reports on whether existing canon concepts provided utility live
+under `feedback/`. That directory is PurposeFit evidence, not a change request
+and not a canon artifact. A need still belongs in `demand/`; a body of knowledge
+still belongs in `incoming/`.
+
 ## Evaluations
 
 Canon-side evaluation packs live under `infospace/evaluations/`. The first pack

canon.yaml

@@ -128,6 +128,9 @@ planned_directories:
   - infospace/examples/
   - infospace/validation/
   - workplans/
+  - demand/
+  - incoming/
+  - feedback/
 
 workplans:
   registry: workplans/index.yaml
@@ -147,6 +150,12 @@ workplans:
     - ITC-WP-0013
     - ITC-WP-0014
 
+feedback:
+  path: feedback/
+  index: feedback/index.yaml
+  practice: feedback/README.md
+  template: feedback/TEMPLATE.md
+
 assimilation:
   practice: infospace/assimilation/intake-and-assimilation-practice.md
   intake_dir: incoming/

demand/CapabilityProvisionEconomics.md

@@ -7,6 +7,7 @@
 **Consumer evidence:** `resource-control` `RESOURCE-WP-0002`, `RESOURCE-WP-0003`
 **Workplan:** `ITC-WP-0014` T08–T10 (findings A, B, and C landed together)
 **Decision:** `infospace/assimilation/it-capability-canon/ASSIMILATION.md`
+**Utility evidence:** `feedback/2026-08-15-resource-control-capability-provision.md`
 
 ---
 

feedback/2026-08-15-resource-control-capability-provision.md

@@ -0,0 +1,113 @@
+---
+id: feedback/2026-08-15-resource-control-capability-provision
+type: consumer-feedback
+status: acted-on
+date: "2026-08-15"
+consumer: resource-control
+consumer_domain: financials
+canon_version: "0.2.1"
+artifacts:
+  - model/capability
+related_demand:
+  - demand/CapabilityProvisionEconomics.md
+related_workplan:
+  - ITC-WP-0014
+spawned_demand:
+  - demand/CapabilityProvisionEconomics.md
+spawned_workplan:
+  - ITC-WP-0014
+---
+
+# Feedback: ITC-CAP on a completed backup procurement cycle
+
+**Consumer:** resource-control (domain `financials`)
+**Canon version used:** 0.2.1 / ITC-CAP 0.1.0
+**Artifacts exercised:** `model/capability` (`data.backup`, `data.object`,
+`security.secrets`, `runtime.scheduling`, `operations.recovery`, D-scale,
+resource classes)
+**Related demand:** `demand/CapabilityProvisionEconomics.md`
+
+Steward-written from the consumer's inbound demand and State Hub message of
+2026-08-15. The consumer completed RESOURCE-WP-0002 — provider selection,
+purchase, credential custody, proven restore and PITR, monthly observation,
+thresholds, and a decided optimization case — then mapped that work onto
+ITC-CAP. This report extracts the *utility* evidence. The three defects are
+demand, already accepted in canon 0.3.0.
+
+---
+
+## Consumer purpose
+
+Own portfolio identity, technical economics, allocation evidence, forecasts,
+and optimization cases for managed infrastructure. For this cycle: select and
+control a real backup resource, and say in canon terms what was required,
+what was provided, how mature it is, and what it consumes.
+
+## Hits
+
+- **`data.backup` catalog entry and its graph.** The work decomposes without
+  strain: object store provides `data.object`; CNPG/Barman provides
+  `data.backup` (profile `database`) which `depends_on` it; credentials are
+  `security.secrets`; schedule is `runtime.scheduling`; the restore drill is
+  evidence for both `data.backup` and `operations.recovery`.
+- **Evidence hooks on `data.backup`.** `successful_backup`,
+  `successful_restore_test`, `measured_rpo`, `measured_rto` matched, one for
+  one, evidence the consumer had already produced before encountering the
+  model. Independent convergence. First backup 48s; full restore 65s with
+  equal row counts; PITR 65s; measured RPO about 2s against a 5-minute
+  `archive_timeout`.
+- **D0–D7 provision maturity.** The consumer assessed their own provision as
+  **D4, not D5**: reliability is declared in thresholds but rests on one
+  backup and four hours of evidence. The scale produced an honest answer
+  instead of a flattering one.
+- **CAP-R2 / CAP-R5 as a design criterion.** The consumer considered splitting
+  ITC-CAP into supply-side and demand-side canons and rejected it: both sides
+  agree about what exists, so two record types on one spine are enough, and
+  splitting would destroy joinable ids. That reasoning is reusable.
+
+## Friction
+
+- **`typical_resource_classes` on the contract.** Contradicted §4.11 and
+  carried almost no information (29 of 41 entries identical). Invited cost
+  structuring on the abstract capability. Filed as demand finding A; removed
+  in ITC-CAP 0.2.0 / canon 0.3.0.
+- **`CapabilityRequirement` was id + `minimum_maturity` only.** The real
+  backup need was profile `database`, RPO ≤ 5 min, retention 30 days, and
+  *not* in the failure domain of the protected host. `isolation` and
+  `geographical_separation` were already named dimensions; the requirement
+  could not use them. Filed as demand finding B; requirement shape enriched
+  in ITC-CAP 0.2.0.
+- **Resource-class set had no human-effort class.** Provider selection
+  inverted on labour (Hetzner cheaper on infrastructure, worse overall by
+  €29.14/month on operator hours). Self-managed option failed on a 4 h/month
+  ceiling, not on money. Hours were often known when currency was not.
+  Intelligence was modelled as one more purchased input. Filed as demand
+  finding C; class `H`, native units, and `I` as substitute landed in
+  ITC-CAP 0.2.0.
+
+## Gaps
+
+The three findings above. No further unnamed concept was claimed. Token
+efficiency was offered as forward-looking rationale (the consumer does not
+yet measure tokens in its portfolio model); `intelligence_intensity` was
+added as a quality dimension so the gap has a home when they do.
+
+## Drop candidates
+
+None claimed. Removing `typical_resource_classes` was a field deletion, not
+a concept retirement. The consumer did not propose dropping any capability
+id.
+
+## Steward notes
+
+- Status `acted-on`: findings A–C accepted and published in canon 0.3.0.
+  Decision record in `infospace/assimilation/it-capability-canon/ASSIMILATION.md`.
+- This report is evidence that ITC-CAP's catalog, evidence hooks, and D-scale
+  already have a real consumer. That is relevant to §10 promotion
+  requirement 3; the consumer has offered to restate the backup case entirely
+  in the 0.2.0 shape (requirement, provision, D4, four hooks, native-unit
+  consumption).
+- Do not generalize from one cycle to "the other 35 capabilities are unused."
+  This cycle only exercised backup-adjacent ids.
+- Do not treat this file as the work item. Changes go through the demand and
+  ITC-WP-0014.

feedback/README.md

@@ -0,0 +1,85 @@
+# feedback/
+
+Consumer reports on whether InfoTechCanon concepts **hit**, **friction**,
+**gap**, or are **drop candidates**.
+
+This is a longitudinal evidence lane. It exists so the canon can see, over
+time, which concepts provide utility and which could be improved or retired —
+without treating every observation as a change request.
+
+**Rules**
+
+- Reports land here as steward-curated files. A consumer may file a report
+  directly, or a steward may write one from a message, evaluation, or completed
+  consumer cycle.
+- Feedback **accumulates**. Do not empty this directory after a session.
+- Feedback is **not a canon artifact**. `canon.yaml`, `infospace/artifacts/`,
+  and model prose must not treat a path under `feedback/` as normative. Workplans,
+  decision records, and `CHANGELOG.md` may *cite* a report as evidence.
+- Do not edit the consumer-authored body after receipt. Steward updates belong
+  in the frontmatter (`status`, `spawned_*`) and in `## Steward notes`.
+- A report is not a work item. If it contains a need, file or link a `demand/`
+  and (if accepted) a workplan.
+
+**Front doors — do not collapse**
+
+| Directory | Holds | Lifecycle | Next step |
+|---|---|---|---|
+| `incoming/` | raw body of knowledge proposed for absorption | empty after processing | assimilation |
+| `demand/` | a stated need for a canon change | reviewed → workplan or reject | design + workplan |
+| `feedback/` | observed utility of *existing* concepts | accumulates | cite; spawn `demand/` only if a gap needs work |
+
+A single consumer cycle may produce both. resource-control's backup mapping is
+the type case: the evidence-hook match is feedback; the three defects were
+demand. File both; link them; do not merge the files.
+
+**Canon home.** A feedback report is PurposeFit evidence (ITC-GOV Purpose and
+Demand extension): how well a producer concept satisfied a consumer purpose.
+It may also carry DemandSignals. It is not an EvolutionRequest until a
+`demand/` is filed.
+
+Promoting `feedback/` into `ITC-REPO-LAYOUT` as an optional producer-repo
+directory is a later question. This directory is established here first.
+
+---
+
+## How to file
+
+Copy [`TEMPLATE.md`](TEMPLATE.md). Name the file:
+
+```text
+YYYY-MM-DD-<consumer>-<slug>.md
+```
+
+Add a row to [`index.yaml`](index.yaml). Do not invent judgments the consumer
+did not make. `unused` is not a judgment — one cycle not touching a concept
+is not evidence it should be dropped.
+
+---
+
+## Status
+
+| Status | Meaning |
+|---|---|
+| `inbound` | filed, not yet read by a canon steward |
+| `reviewed` | read; judgments accepted as evidence; no change spawned |
+| `acted-on` | spawned or satisfied a `demand/` / workplan / canon change |
+| `noted` | read; recorded; no action and none expected |
+
+---
+
+## Judgments
+
+| Judgment | Meaning |
+|---|---|
+| `hits` | used as specified; provided utility |
+| `friction` | used, but incomplete, misplaced, or in the way |
+| `gaps` | needed something the canon does not name |
+| `drop_candidates` | consumer would not miss this concept; high bar — unused ≠ drop |
+
+---
+
+## Reports
+
+See [`index.yaml`](index.yaml) for the rollup. Each report is a sibling
+Markdown file in this directory.

feedback/TEMPLATE.md

@@ -0,0 +1,51 @@
+---
+id: feedback/YYYY-MM-DD-<consumer>-<slug>
+type: consumer-feedback
+status: inbound
+date: "YYYY-MM-DD"
+consumer: <repo-or-agent-name>
+consumer_domain: <domain or unknown>
+canon_version: "<version the consumer used>"
+artifacts: []
+related_demand: []
+related_workplan: []
+spawned_demand: []
+spawned_workplan: []
+---
+
+# Feedback: <one-line title>
+
+**Consumer:**
+**Canon version used:**
+**Artifacts exercised:**
+**Related demand:** none | `demand/<file>.md`
+
+---
+
+## Consumer purpose
+
+What the consumer was trying to do. One short paragraph. Not a feature request.
+
+## Hits
+
+Concepts, ids, or rules that were used as specified and provided utility.
+Each item: the id or name, what they did with it, and why it counted as a hit.
+
+## Friction
+
+Concepts that were used but incomplete, misplaced, or in the way.
+Each item: the id, what went wrong, and whether a `demand/` was filed.
+
+## Gaps
+
+Needed something the canon does not name. Usually becomes `demand/`.
+
+## Drop candidates
+
+Only if the consumer would not miss the concept. Unused in this cycle is not
+enough. High bar; this list is often empty.
+
+## Steward notes
+
+Canon-side disposition. Status, links to spawned demand or work, and any
+limit on how far this report should be generalized.

feedback/index.yaml

@@ -0,0 +1,44 @@
+# Rollup of consumer feedback reports. Hand-maintained.
+# Normative canon artifacts must not depend on this file.
+directory: feedback
+purpose: Consumer reports on whether InfoTechCanon concepts provide utility
+updated: "2026-08-15"
+judgments:
+  - hits
+  - friction
+  - gaps
+  - drop_candidates
+reports:
+  - id: feedback/2026-08-15-resource-control-capability-provision
+    path: feedback/2026-08-15-resource-control-capability-provision.md
+    date: "2026-08-15"
+    consumer: resource-control
+    consumer_domain: financials
+    status: acted-on
+    canon_version: "0.2.1"
+    artifacts:
+      - model/capability
+    hits:
+      - data.backup
+      - data.object
+      - security.secrets
+      - runtime.scheduling
+      - operations.recovery
+      - CapabilityEvidenceHook
+      - CapabilityMaturityLevel
+      - CAP-R2
+      - CAP-R5
+    friction:
+      - typical_resource_classes
+      - CapabilityRequirement
+      - CapabilityResourceClass
+    gaps:
+      - human-effort resource class
+      - requirement targets and constraints
+      - native-unit consumption
+    drop_candidates: []
+    related_demand:
+      - demand/CapabilityProvisionEconomics.md
+    related_workplan:
+      - ITC-WP-0014
+    spawned_canon_version: "0.3.0"

incoming/README.md

@@ -22,3 +22,6 @@ notes in `CHANGELOG.md`.
 
 If an input is a *need* rather than a body of knowledge, it belongs in `demand/`
 with a workplan, not here.
+
+If an input is a report on whether *existing* canon concepts provided utility,
+it belongs in `feedback/`, not here.

infospace/assimilation/intake-and-assimilation-practice.md

@@ -54,12 +54,17 @@ Related but distinct front doors — do not confuse them:
 | Directory | Holds | Next step |
 |---|---|---|
 | `incoming/` | raw candidate material to absorb | this practice |
-| `demand/` | a stated consumer need, not yet a document | workplan + design |
+| `demand/` | a stated consumer need, not yet a work item | workplan + design |
+| `feedback/` | observed utility of existing canon concepts | cite; spawn `demand/` only if a gap needs work |
 | `seeds/` | historical provenance of first-generation canon files | frozen |
 
 If an input turns out to be a *need* rather than a *body of knowledge*, move it to
 `demand/` and open a workplan instead of an assimilation workspace.
 
+If an input is a report on whether existing concepts hit or missed, move it to
+`feedback/`. A single arrival may split: utility evidence stays in `feedback/`,
+requested changes go to `demand/`.
+
 ---
 
 ## 3. Stage 1 — Intake

workplans/ADHOC-2026-08-15.md

@@ -0,0 +1,50 @@
+---
+id: ADHOC-2026-08-15
+type: workplan
+title: "Ad hoc: consumer feedback directory"
+domain: infotech
+topic_slug: canon
+repo: info-tech-canon
+status: finished
+priority: low
+created: "2026-08-15"
+updated: "2026-08-15"
+owner: grok
+spec_refs:
+  - feedback/README.md
+  - demand/CapabilityProvisionEconomics.md
+---
+
+# ADHOC-2026-08-15 — Consumer feedback directory
+
+## Goal
+
+Give the canon a durable place to collect consumer reports on whether
+existing concepts hit, friction, gap, or are drop candidates — without
+collapsing that evidence into `demand/` or `incoming/`.
+
+## Tasks
+
+### T01 — Establish `feedback/` front door
+
+```task
+id: ADHOC-2026-08-15-T01
+status: done
+priority: medium
+```
+
+Add `feedback/README.md`, `TEMPLATE.md`, and `index.yaml`. Distinguish the
+directory from `demand/` and `incoming/` in those files and in the intake
+practice. Register the path in `canon.yaml`. Not a canon artifact.
+
+### T02 — Seed first report from resource-control
+
+```task
+id: ADHOC-2026-08-15-T02
+status: done
+priority: medium
+```
+
+Write `feedback/2026-08-15-resource-control-capability-provision.md` from the
+2026-08-15 backup-cycle mapping. Hits stay here; the three defects remain
+`demand/CapabilityProvisionEconomics.md`.

workplans/index.yaml

@@ -207,3 +207,13 @@ workplans:
       - formal capability mapping artifacts
       - small-saas capability requirement set
       - capability requirement/provision validation surface
+
+  - id: ADHOC-2026-08-15
+    title: "Ad hoc: consumer feedback directory"
+    status: finished
+    priority: low
+    path: workplans/ADHOC-2026-08-15.md
+    depends_on: []
+    produces:
+      - feedback/
+      - first consumer utility report (resource-control / ITC-CAP)