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.

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.