@sdd-method/sdd-cli 1.23.1 → 1.24.0

package/dist/lib/catalogue/canonical-schema.yaml

@@ -1,22 +1,17 @@
 # GENERATED — DO NOT EDIT. This file is a projection of the authored model (M-ADR 0210 §4.6, flip 1):
 #   docs/method/foundations/schemas/catalogue-schema.tql        (the type system; header carries the bump log)
 #   docs/method/foundations/schemas/catalogue-schema-meta.tql   (what a type system cannot say)
-# Regenerate:  python3 orchestration/scripts/check-catalogue-schema-roundtrip.py --write
-# Guard:       python3 orchestration/scripts/check-catalogue-schema-roundtrip.py   (any difference fails the build)
+# Regenerate:  sdd-cli metamodel roundtrip --write
+# Guard:       sdd-cli metamodel roundtrip   (any difference fails the build)
 # Direction of truth: authored .tql -> this projection (round-trip gate) -> vendored copies (digest hook).
-# Emitted with PyYAML safe_dump(sort_keys=False, allow_unicode=True, width=1000000); the three header scalars
-# are quoted for the textual readers downstream. The one deliberate
-# difference from the authored form is schema_status: the authored form says canonical; a projection never does.
+# Emitted by sdd-cli's YAML emitter with no line folding; the three header scalars are quoted for the
+# textual readers downstream. The one deliberate difference from the authored form is schema_status:
+# the authored form says canonical; a projection never does.
 schema_version: "3.10.0"
 schema_owner: "sdd-method"
 schema_status: "generated"
 enums:
   quality_gate:
-    description: 'Gate verdict a rubric assessment records for a target, in `quality_scores.gate` (per M-ADR 0205 §4.5). The vocabulary all fifteen method-side gate registries declare.
-
-      DELIBERATELY NOT BOUND via `column_enums`, and the reason is measured rather than assumed — do not "fix" this by binding it. These values come from hand-authored score registries written by scoring runs, not from a method-mandated authoring surface, and one estate''s `domain-architecture-scores.yaml` declared `pass-with-waiver` before the method did, and uses it — the extension was RULED INTO this vocabulary (2026-08-07); the next estate extension would meet the same choice, and binding would hard-fail a build over a deliberate, self-documented row. This follows the `products.synthesis_band` precedent — the other column fed from a rubric registry — where an out-of-vocabulary value is reported as a convention finding and the cell left EMPTY, rather than emitting a value no consumer can interpret. The builder names the file, the entry, the value and the remedy, which is better diagnosis than a generic enum violation could give. Contrast `service_type`, which IS bound: it comes from repo-config, an authoring surface the method mandates.
-
-      '
     values:
     - value: pass
       description: Meets the rubric's pass threshold with no hard gate triggered.
@@ -27,11 +22,11 @@ enums:
     - value: fail
       description: Below the fail threshold, or a hard gate triggered.
     - value: unscored
-      description: 'The entry exists but carries no assessment. Distinct from absent: an unscored row asserts that nothing has been judged, which is exactly the silence M-ADR 0205 §4.5''s coverage instrument exists to make loud.'
+      description: "The entry exists but carries no assessment. Distinct from absent: an unscored row asserts that nothing has been judged, which is exactly the silence M-ADR 0205 §4.5's coverage instrument exists to make loud."
+    description: |
+      Gate verdict a rubric assessment records for a target, in `quality_scores.gate` (per M-ADR 0205 §4.5). The vocabulary all fifteen method-side gate registries declare.
+      DELIBERATELY NOT BOUND via `column_enums`, and the reason is measured rather than assumed — do not "fix" this by binding it. These values come from hand-authored score registries written by scoring runs, not from a method-mandated authoring surface, and one estate's `domain-architecture-scores.yaml` declared `pass-with-waiver` before the method did, and uses it — the extension was RULED INTO this vocabulary (2026-08-07); the next estate extension would meet the same choice, and binding would hard-fail a build over a deliberate, self-documented row. This follows the `products.synthesis_band` precedent — the other column fed from a rubric registry — where an out-of-vocabulary value is reported as a convention finding and the cell left EMPTY, rather than emitting a value no consumer can interpret. The builder names the file, the entry, the value and the remedy, which is better diagnosis than a generic enum violation could give. Contrast `service_type`, which IS bound: it comes from repo-config, an authoring surface the method mandates.
   score_selection_method:
-    description: 'How the effective review was chosen from a target''s review history, in `quality_scores.selection_method` — the `selection_policy.method` field every gate registry carries. The catalogue models only the EFFECTIVE score (one row per target/rubric); this column makes the row say WHICH review it is rather than implying there was only one. Not bound, for the same registry-authored reason as `quality_gate`.
-
-      '
     values:
     - value: latest
       description: Most recent review by scored_at. The default and, at 2026-08-06, the only value in use across either estate.
@@ -41,10 +36,9 @@ enums:
       description: Effective score reconciled across several reviews.
     - value: highest-severity
       description: The most severe review wins — the conservative policy for gate-blocking rubrics.
+    description: |
+      How the effective review was chosen from a target's review history, in `quality_scores.selection_method` — the `selection_policy.method` field every gate registry carries. The catalogue models only the EFFECTIVE score (one row per target/rubric); this column makes the row say WHICH review it is rather than implying there was only one. Not bound, for the same registry-authored reason as `quality_gate`.
   staleness_basis:
-    description: 'Which anchor a `quality_scores` row''s staleness verdict can be computed from, in `quality_scores.staleness_basis`. This column exists because a staleness verdict whose basis is unstated is not a measurement — the basis-error class that produced six wrong figures in a single day of this method''s own arc. The coverage predicate MUST NOT be able to emit a staleness claim without naming which of these it used.
-
-      '
     values:
     - value: corpus_ref
       description: The row carries the commit the assessment read — the precise anchor. Authored; introduced by the M-ADR 0205 §4.5 change-set, so absent from every score written before it.
@@ -52,23 +46,19 @@ enums:
       description: No corpus_ref; staleness computed from the assessment date against the target's last content change, resolved through target_path. Correct but coarser — it cannot distinguish a re-commit that changed nothing from a real edit.
     - value: none
       description: Neither anchor available (no corpus_ref and no resolvable target_path). Staleness is UNKNOWN for this row and must be reported as unknown, never as fresh.
+    description: |
+      Which anchor a `quality_scores` row's staleness verdict can be computed from, in `quality_scores.staleness_basis`. This column exists because a staleness verdict whose basis is unstated is not a measurement — the basis-error class that produced six wrong figures in a single day of this method's own arc. The coverage predicate MUST NOT be able to emit a staleness claim without naming which of these it used.
   scoring_form:
-    description: 'The scoring shape a rubric uses, in `quality_scores.scoring_form`. Reserved by M-ADR 0205 §4.5 so the banded reverse family can arrive additively without reshaping rows.
-
-      Both forms are now declared. `banded` was added in 3.3.0 once the reverse family was modelled; before that it was deliberately absent so a premature banded row would fail loudly rather than pass against an unemitted value.
-
-      The two forms are NOT interchangeable and must not be averaged together — which is why they never share a score column. A weighted row carries `weighted_score` (1-5) and leaves `band`/`band_total` empty; a banded row carries `band` + `band_total` and leaves `weighted_score` empty. Any aggregate over `weighted_score` is therefore correct by construction rather than by the caller remembering to filter.
-
-      '
     values:
     - value: weighted
       description: Weighted 1-5 dimensions rolled into a weighted_score against a pass threshold, with flags and hard gates. The forward house form; all fifteen method-side registries use it.
     - value: banded
       description: Dimensions summed to an integer total and mapped to a named band. The reverse family's form. Added in 3.3.0. The band vocabulary is PER-RUBRIC and deliberately unbound — see the band column.
+    description: |
+      The scoring shape a rubric uses, in `quality_scores.scoring_form`. Reserved by M-ADR 0205 §4.5 so the banded reverse family can arrive additively without reshaping rows.
+      Both forms are now declared. `banded` was added in 3.3.0 once the reverse family was modelled; before that it was deliberately absent so a premature banded row would fail loudly rather than pass against an unemitted value.
+      The two forms are NOT interchangeable and must not be averaged together — which is why they never share a score column. A weighted row carries `weighted_score` (1-5) and leaves `band`/`band_total` empty; a banded row carries `band` + `band_total` and leaves `weighted_score` empty. Any aggregate over `weighted_score` is therefore correct by construction rather than by the caller remembering to filter.
   capability_service_role:
-    description: 'The part a service plays in delivering ONE capability. A property of the capability↔service RELATIONSHIP, never of the service: the same service is legitimately `primary` for capabilities in its own domain and `backend-gateway` for capabilities elsewhere. Authored in the capability traceability manifest services[].role (see the capability-traceability-manifest-template). Bound in 3.8.0; the values and their meanings are the template''s, unchanged. Consumers deriving "which repos realise this capability" MUST read this column or use repo_capability, which excludes `dependency` (M-ADR 0157 §4.3 as amended) — a repo_capability row is a contribution claim.
-
-      '
     values:
     - value: primary
       description: Realises this capability.
@@ -78,8 +68,9 @@ enums:
       description: This capability DEPENDS ON the service — the inverse direction of contribution. The relationship is real and catalogued here; it does NOT produce a repo_capability row.
     - value: backend-gateway
       description: Owned by ANOTHER domain and the sanctioned entry point into that domain's data for this capability — not merely a dependency, the door in. Expect it on cross-domain rows only. Contributes; kept in repo_capability.
+    description: |
+      The part a service plays in delivering ONE capability. A property of the capability↔service RELATIONSHIP, never of the service: the same service is legitimately `primary` for capabilities in its own domain and `backend-gateway` for capabilities elsewhere. Authored in the capability traceability manifest services[].role (see the capability-traceability-manifest-template). Bound in 3.8.0; the values and their meanings are the template's, unchanged. Consumers deriving "which repos realise this capability" MUST read this column or use repo_capability, which excludes `dependency` (M-ADR 0157 §4.3 as amended) — a repo_capability row is a contribution claim.
   c4_system_kind:
-    description: "Architectural kind of a C4 system. Derived 1:1 from the originating SDD manifest's category — every architectural product (the only ones that get a c4_systems row) maps to exactly one of these four kinds. Non-architectural categories (integration-umbrella, support-repo) emit no c4_systems row — and the builder MUST say so with a coverage finding, never silently (M-ADR 0133 §4.2c). Mapping table:\n  platform-root        → platform\n  platform-subsystem   → subsystem\n  application-product  → application\n  integration-provider → integration\n"
     values:
     - value: platform
       description: A platform-root system — the one system that identifies a platform (M-ADR 0208 §4.1; 'platform-ecosystem' is the long form, 1:1 with the root). Exactly one per PLATFORM; an organisation-tier aggregate legitimately carries one per constituent platform, keyed by platform_sdd_id (0208 §4.2). An invariant `subsystem` exists to protect — do not reuse `platform` for subsystem rows.
@@ -89,21 +80,22 @@ enums:
       description: An application-product system, consumes platform services and contracts.
     - value: integration
       description: An integration-provider system, bridges an external provider into the platform.
+    description: |
+      Architectural kind of a C4 system. Derived 1:1 from the originating SDD manifest's category — every architectural product (the only ones that get a c4_systems row) maps to exactly one of these four kinds. Non-architectural categories (integration-umbrella, support-repo) emit no c4_systems row — and the builder MUST say so with a coverage finding, never silently (M-ADR 0133 §4.2c). Mapping table:
+        platform-root        → platform
+        platform-subsystem   → subsystem
+        application-product  → application
+        integration-provider → integration
   c4_container_type:
-    description: 'Canonical C4 container kind for `c4_containers.type`, aligned with c4model.com/abstractions (per M-ADR 0155). A C4 container is something that must be running for the system to work — an application or a data store.
-
-      BOUND via `c4_containers.column_enums` since 3.0.0 (M-ADR 0203 §4.1, completing 0155''s staged enforcement): a non-member value hard-fails build and validate. The 2.x-era legacy values are removed; their migration rule (0155''s own): `External System` boxes belong in `c4_external_systems` (C4 L1 peer systems, not L2 containers); running infrastructure (broker, gateway, cache) retypes to Application or Data Store; pure deployment infrastructure (load balancer, DNS) leaves the container catalogue (it belongs in a C4 deployment diagram, which is not catalogued).
-
-      '
     values:
     - value: Application
       description: A separately deployable/runnable application — a service, BFF, UI, consumer, worker, etc.
     - value: Data Store
       description: A database or persistence layer (also covers running stores like a message broker when modelled as a container).
+    description: |
+      Canonical C4 container kind for `c4_containers.type`, aligned with c4model.com/abstractions (per M-ADR 0155). A C4 container is something that must be running for the system to work — an application or a data store.
+      BOUND via `c4_containers.column_enums` since 3.0.0 (M-ADR 0203 §4.1, completing 0155's staged enforcement): a non-member value hard-fails build and validate. The 2.x-era legacy values are removed; their migration rule (0155's own): `External System` boxes belong in `c4_external_systems` (C4 L1 peer systems, not L2 containers); running infrastructure (broker, gateway, cache) retypes to Application or Data Store; pure deployment infrastructure (load balancer, DNS) leaves the container catalogue (it belongs in a C4 deployment diagram, which is not catalogued).
   service_type:
-    description: 'Type of repository, declared in `orchestration/repo-config/*.yaml` as `service_type` and surfaced in `repositories.component_type` and `services.component_type`. The canonical builder uses this to decide which repos are runtime services (api_service, worker, gateway, frontend, mobile) and which are non-runtime (library, infrastructure, documentation). Whether a repo is a vertical-domain application is conveyed by its SDD manifest''s `profile: application-product`, not by a service_type tag — this enum is strictly about runtime artefact shape (per resolution of adopt-canonical-catalogue-builder.md §7.1).
-
-      '
     values:
     - value: api_service
       description: REST/GraphQL/RPC service exposing an API.
@@ -137,12 +129,9 @@ enums:
       description: Docs-only repo.
       runtime: false
       emits_service_row: false
+    description: |
+      Type of repository, declared in `orchestration/repo-config/*.yaml` as `service_type` and surfaced in `repositories.component_type` and `services.component_type`. The canonical builder uses this to decide which repos are runtime services (api_service, worker, gateway, frontend, mobile) and which are non-runtime (library, infrastructure, documentation). Whether a repo is a vertical-domain application is conveyed by its SDD manifest's `profile: application-product`, not by a service_type tag — this enum is strictly about runtime artefact shape (per resolution of adopt-canonical-catalogue-builder.md §7.1).
   capability_exemption_reason:
-    description: 'Why a catalogued repository deliberately bears no capability, per M-ADR 0188 §4.2. Closed vocabulary: reason codes make exemptions countable and trendable (a growing `prototype` or `archived` population is itself an estate signal), where free text would bury them. Extensions are method-owned and proceed by ADR amendment, so that adopters cannot locally widen the exemption surface to silence findings.
-
-      ENFORCED, not advisory. The builder drops a `repo_capability_exemption` row whose reason is outside this vocabulary and emits a `convention` finding. The repository then resolves to nothing and is reported as an orphan — which is the point. If an unrecognised reason still exempted the repo, `reason: whatever` would be a universal silencer.
-
-      '
     values:
     - value: infrastructure
       description: Provisions or operates the estate; realises no product capability.
@@ -156,23 +145,19 @@ enums:
       description: Exploratory; not part of the product model.
     - value: archived
       description: Retained for reference; no longer live.
+    description: |
+      Why a catalogued repository deliberately bears no capability, per M-ADR 0188 §4.2. Closed vocabulary: reason codes make exemptions countable and trendable (a growing `prototype` or `archived` population is itself an estate signal), where free text would bury them. Extensions are method-owned and proceed by ADR amendment, so that adopters cannot locally widen the exemption surface to silence findings.
+      ENFORCED, not advisory. The builder drops a `repo_capability_exemption` row whose reason is outside this vocabulary and emits a `convention` finding. The repository then resolves to nothing and is reported as an orphan — which is the point. If an unrecognised reason still exempted the repo, `reason: whatever` would be a universal silencer.
   service_capability_exemption_reason:
-    description: 'Why a catalogued service deliberately bears no capability, per M-ADR 0133 §4.2b. Closed vocabulary — narrower than `capability_exemption_reason` by design: a repository can be exempt for six reasons (packaging, tooling, provenance), but a SERVICE, by definition, already runs something — the repository-tier distinctions that don''t reproduce at the service tier (pure IaC, build tooling, test scaffolding, vendored code) fold into `platform-internal`, since a service that exists at all is doing platform-internal work if it isn''t product-facing.
-
-      ENFORCED, not advisory. The builder drops a `service_capability_exemption` row whose reason is outside this vocabulary and emits a `convention` finding. The service then resolves to nothing and is reported per the coverage predicate''s tier-scoped verdict set — which is the point.
-
-      '
     values:
     - value: platform-internal
       description: Runs, but serves the platform's own operation rather than a product capability (e.g. an internal control-plane or ops service).
     - value: deprecated
       description: No longer live; retained for reference or wind-down.
+    description: |
+      Why a catalogued service deliberately bears no capability, per M-ADR 0133 §4.2b. Closed vocabulary — narrower than `capability_exemption_reason` by design: a repository can be exempt for six reasons (packaging, tooling, provenance), but a SERVICE, by definition, already runs something — the repository-tier distinctions that don't reproduce at the service tier (pure IaC, build tooling, test scaffolding, vendored code) fold into `platform-internal`, since a service that exists at all is doing platform-internal work if it isn't product-facing.
+      ENFORCED, not advisory. The builder drops a `service_capability_exemption` row whose reason is outside this vocabulary and emits a `convention` finding. The service then resolves to nothing and is reported per the coverage predicate's tier-scoped verdict set — which is the point.
   external_system_exemption_reason:
-    description: 'Why an external-system candidate is ACCOUNTED FOR at the estate boundary, per M-ADR 0189 §4.6 (WS15; wording corrected by F16, 2.32.0): five values assert another party owns the system, and two assert the estate/organisation owns it but it has no model home yet — forcing the latter through the former would demand a false reason, and a false reason is worse than silence. The adjudicator can prove a candidate internal; it cannot prove one accounted-for — that is an assertion the author is accountable for, in the shape M-ADR 0188 ratified for repositories. Closed vocabulary, method-owned, extended only by ADR amendment, so adopters cannot locally widen the exemption surface to silence the unverified-candidate coverage finding.
-
-      ENFORCED, not advisory: the builder drops a row whose reason is outside this vocabulary (convention finding) and the candidate stays unverified — which is the point. An unrecognised reason must not succeed at the one thing an exemption does.
-
-      '
     values:
     - value: third-party-saas
       description: An operated vendor service the estate consumes (billing, auth, maps, email…).
@@ -185,22 +170,21 @@ enums:
     - value: public-infrastructure
       description: Public networks, registries, or services no party in the estate operates.
     - value: estate-owned-unmodelled
-      description: 'Operated by this estate but with no SDD or container home yet — the row is an accounted-for stand-in, and this population is the estate''s modelling backlog, countable (F16, 2.32.0). Not an assertion of externality: an assertion of accountability for a boundary row.'
+      description: "Operated by this estate but with no SDD or container home yet — the row is an accounted-for stand-in, and this population is the estate's modelling backlog, countable (F16, 2.32.0). Not an assertion of externality: an assertion of accountability for a boundary row."
     - value: organisation-internal
       description: Owned elsewhere in the same organisation, outside this estate's modelling boundary (F16, 2.32.0).
+    description: |
+      Why an external-system candidate is ACCOUNTED FOR at the estate boundary, per M-ADR 0189 §4.6 (WS15; wording corrected by F16, 2.32.0): five values assert another party owns the system, and two assert the estate/organisation owns it but it has no model home yet — forcing the latter through the former would demand a false reason, and a false reason is worse than silence. The adjudicator can prove a candidate internal; it cannot prove one accounted-for — that is an assertion the author is accountable for, in the shape M-ADR 0188 ratified for repositories. Closed vocabulary, method-owned, extended only by ADR amendment, so adopters cannot locally widen the exemption surface to silence the unverified-candidate coverage finding.
+      ENFORCED, not advisory: the builder drops a row whose reason is outside this vocabulary (convention finding) and the candidate stays unverified — which is the point. An unrecognised reason must not succeed at the one thing an exemption does.
   scaffold_status:
-    description: 'Lifecycle of a scaffold declaration, in `scaffolds.status`. AUTHORED in the manifest, copied by the builder: closing a scaffold is a recorded act of the unit of work finishing (M-ADR 0207 §4.3), not a computed consequence — the delta instrument reports a closed scaffold whose delta is not zero as a finding, it never closes one itself.
-
-      '
     values:
     - value: open
       description: The unit of work is in flight. `declared` items are a state, not a defect (M-ADR 0207 §4.2).
     - value: closed
       description: The author has recorded the unit of work as done. A `declared` item under a closed scaffold presumes the scaffold right — the work is incomplete — and is reported (M-ADR 0207 §4.3).
+    description: |
+      Lifecycle of a scaffold declaration, in `scaffolds.status`. AUTHORED in the manifest, copied by the builder: closing a scaffold is a recorded act of the unit of work finishing (M-ADR 0207 §4.3), not a computed consequence — the delta instrument reports a closed scaffold whose delta is not zero as a finding, it never closes one itself.
   scaffold_item_kind:
-    description: 'The grain of a scaffold declaration item, in `scaffold_items.item_kind`. Declares which family of catalogue surface the item promises; `target_kind` names the specific catalogue.
-
-      '
     values:
     - value: entity
       description: A node catalogue row the work will add (a service, capability, feature, screen, …). target_ref is the declared id in that catalogue's vocabulary.
@@ -208,17 +192,17 @@ enums:
       description: An edge catalogue row the work will add. Endpoints are declared in edge_source_ref/edge_target_ref, mapped to the edge catalogue's FK columns in schema declaration order.
     - value: contract
       description: A contract artefact the work will introduce or amend. target_ref is the repo-relative spec path, matching `contracts.spec_path`.
+    description: |
+      The grain of a scaffold declaration item, in `scaffold_items.item_kind`. Declares which family of catalogue surface the item promises; `target_kind` names the specific catalogue.
   scaffold_item_state:
-    description: 'Realisation state of a scaffold item, in `scaffold_items.state`. DERIVED by the builder''s resolution pass against the same build''s catalogue rows — never authored. The manifest declares intent; this column records whether the intent is realised in the corpus the build read. Staleness is deliberately NOT a value here: it is a coverage-time verdict against `scaffolds.corpus_ref` (M-ADR 0207 §4.6), because a git-derived value in a derived row would break rebuild determinism against unchanged authored inputs.
-
-      '
     values:
     - value: declared
       description: The target does not (yet) resolve in the built catalogues. Under an open scaffold this is the computable backlog; under a closed one it is a reported finding (M-ADR 0207 §4.2/§4.3).
     - value: realised
       description: The target resolves in the built catalogues. The declaration is met for this item.
+    description: |
+      Realisation state of a scaffold item, in `scaffold_items.state`. DERIVED by the builder's resolution pass against the same build's catalogue rows — never authored. The manifest declares intent; this column records whether the intent is realised in the corpus the build read. Staleness is deliberately NOT a value here: it is a coverage-time verdict against `scaffolds.corpus_ref` (M-ADR 0207 §4.6), because a git-derived value in a derived row would break rebuild determinism against unchanged authored inputs.
   interaction_pattern:
-    description: 'How a capability''s declared dependency on a service is coupled at RUNTIME — M-ADR 0171''s closed interaction-pattern vocabulary (the union of its ingestion and invocation sets), reused on `capability_service.interaction_pattern` per M-ADR 0211 §4.1 and not widened. BOUND because the value comes from the traceability manifest, a method-mandated authoring surface (M-ADR 0210 §4.5). A NON-RUNTIME coupling — build-time code generation, a load-time singleton, packaging, an authoring sequence — leaves the column EMPTY and states its kind in the manifest''s dependency_notes; that is T4''s excluded-by-class case and reaches no band 5. An entry declares ONE coupling: two tokens in one entry is two entries. Measured at two estates before binding: 17 of 18 runtime couplings mapped onto exactly one token; none needed a token the vocabulary lacks.'
     values:
     - value: event-stream-consume
       description: Subscribe to and drain a broker / stream / feed the provider produces; the consumer drains a durable, ordered channel (Event-Driven / Polling Consumer over a Message Channel).
@@ -234,27 +218,27 @@ enums:
       description: Submit a request; the result returns later via a separate channel, correlated by identifier (Request-Reply, asynchronous + Correlation Identifier).
     - value: publish
       description: Fire-and-forget write to a broker / queue / endpoint with no awaited response (Publish-Subscribe / fire-and-forget Message).
+    description: "How a capability's declared dependency on a service is coupled at RUNTIME — M-ADR 0171's closed interaction-pattern vocabulary (the union of its ingestion and invocation sets), reused on `capability_service.interaction_pattern` per M-ADR 0211 §4.1 and not widened. BOUND because the value comes from the traceability manifest, a method-mandated authoring surface (M-ADR 0210 §4.5). A NON-RUNTIME coupling — build-time code generation, a load-time singleton, packaging, an authoring sequence — leaves the column EMPTY and states its kind in the manifest's dependency_notes; that is T4's excluded-by-class case and reaches no band 5. An entry declares ONE coupling: two tokens in one entry is two entries. Measured at two estates before binding: 17 of 18 runtime couplings mapped onto exactly one token; none needed a token the vocabulary lacks."
   event_participation:
-    description: 'The part a service, capability or feature plays toward an event, in `service_event.role`, `capability_event.role` and `feature_event.role`. `service_event.role` is also M-ADR 0206 §4.2''s role-conditional impact flow (publishes → toward-target, consumes → toward-source). Bound at 3.9.0 (M-ADR 0210 §4.5): the values come from repo-config and derived edges, method-mandated surfaces; every row at both adopter estates'' committed aggregates was in-vocabulary when bound.'
     values:
     - value: publishes
       description: The participant emits the event.
     - value: consumes
       description: The participant receives the event.
+    description: "The part a service, capability or feature plays toward an event, in `service_event.role`, `capability_event.role` and `feature_event.role`. `service_event.role` is also M-ADR 0206 §4.2's role-conditional impact flow (publishes → toward-target, consumes → toward-source). Bound at 3.9.0 (M-ADR 0210 §4.5): the values come from repo-config and derived edges, method-mandated surfaces; every row at both adopter estates' committed aggregates was in-vocabulary when bound."
   contract_participation:
-    description: The part a service plays toward a contract, in `service_contract.role`. Bound at 3.9.0 (M-ADR 0210 §4.5); one estate's rows were all `exposes`, the other's all `consumes` — the union is the vocabulary, and each estate's usage was in it.
     values:
     - value: exposes
       description: The service publishes the contract as its own surface.
     - value: consumes
       description: The service depends on a contract another service exposes.
+    description: The part a service plays toward a contract, in `service_contract.role`. Bound at 3.9.0 (M-ADR 0210 §4.5); one estate's rows were all `exposes`, the other's all `consumes` — the union is the vocabulary, and each estate's usage was in it.
   consumption_role:
-    description: 'The part a product plays toward a capability or service it depends on, in `product_capability.role` and `product_service.role`. EXACTLY ONE VALUE, deliberately: every row at both estates carries `consumes`, and a column with one value is a population of one (M-ADR 0200 §4.10). Bound so the constant is DECLARED rather than accidental — a second value arriving is then a vocabulary decision with a finding, not a silent widening.'
     values:
     - value: consumes
       description: The product depends on / consumes the target.
+    description: "The part a product plays toward a capability or service it depends on, in `product_capability.role` and `product_service.role`. EXACTLY ONE VALUE, deliberately: every row at both estates carries `consumes`, and a column with one value is a population of one (M-ADR 0200 §4.10). Bound so the constant is DECLARED rather than accidental — a second value arriving is then a vocabulary decision with a finding, not a silent widening."
   journey_participation:
-    description: 'The kind of participation a persona has in a user journey, in `persona_journey.role` — the ADR 0210 worked example''s `participation`. Bound at 3.9.0 (M-ADR 0210 §4.5): parsed from the persona spec''s declared `Roles:` line, a method template surface; every row at both estates was in-vocabulary when bound.'
     values:
     - value: primary
       description: The persona the journey is designed around.
@@ -262,6 +246,7 @@ enums:
       description: A persona the journey passes to or from.
     - value: supporting
       description: A persona present in the journey without owning it.
+    description: "The kind of participation a persona has in a user journey, in `persona_journey.role` — the ADR 0210 worked example's `participation`. Bound at 3.9.0 (M-ADR 0210 §4.5): parsed from the persona spec's declared `Roles:` line, a method template surface; every row at both estates was in-vocabulary when bound."
 catalogues:
   domains:
     primary_key: id
@@ -320,7 +305,7 @@ catalogues:
     - name: category
       type: string
       nullable: true
-      description: 'Architectural classification per docs/method/methods/standards/product-category-taxonomy.md. Values: platform-root | platform-subsystem | application-product | integration-provider | integration-umbrella | support-repo. Determines whether the Product gets a c4_systems row.'
+      description: "Architectural classification per docs/method/methods/standards/product-category-taxonomy.md. Values: platform-root | platform-subsystem | application-product | integration-provider | integration-umbrella | support-repo. Determines whether the Product gets a c4_systems row."
     - name: doc_path
       type: string
       nullable: false
@@ -328,7 +313,7 @@ catalogues:
     - name: lifecycle
       type: string
       nullable: true
-      description: 'planned | active | deprecated (default active when empty). Owner-declared product lifecycle from the SDD manifest''s lifecycle: field (sdd-manifest-schema 1.1.0; `planned` added 1.9.0 / catalogue 2.47.0). `planned` = the product is real and intended but does not exist yet, which is the normal opening state of a forward-authored product — so a forward estate that has generated nothing should read `planned`, not the `active` the empty default implies. Distinct from status (documentation maturity): lifecycle is a fact about the PRODUCT, status about the DOCUMENT, and both can hold at once — a product can be reviewed AND deprecated, or planned AND thinly documented. Added in 2.22.0.'
+      description: "planned | active | deprecated (default active when empty). Owner-declared product lifecycle from the SDD manifest's lifecycle: field (sdd-manifest-schema 1.1.0; `planned` added 1.9.0 / catalogue 2.47.0). `planned` = the product is real and intended but does not exist yet, which is the normal opening state of a forward-authored product — so a forward estate that has generated nothing should read `planned`, not the `active` the empty default implies. Distinct from status (documentation maturity): lifecycle is a fact about the PRODUCT, status about the DOCUMENT, and both can hold at once — a product can be reviewed AND deprecated, or planned AND thinly documented. Added in 2.22.0."
     - name: deprecated_date
       type: date
       nullable: true
@@ -336,31 +321,31 @@ catalogues:
     - name: successor_sdd_id
       type: string
       nullable: true
-      description: 'For deprecated products: sdd_id of the superseding SDD. Same vocabulary as sdd_id/source_sdd_id (NOT products.id). Soft reference — the aggregator orphan-checks it against contributing sdd_ids ([finding] orphan when unresolved), never a hard FK: the successor may live outside the aggregation scope. Added in 2.22.0.'
+      description: "For deprecated products: sdd_id of the superseding SDD. Same vocabulary as sdd_id/source_sdd_id (NOT products.id). Soft reference — the aggregator orphan-checks it against contributing sdd_ids ([finding] orphan when unresolved), never a hard FK: the successor may live outside the aggregation scope. Added in 2.22.0."
     - name: exemplar
       type: string
       nullable: true
-      description: '`true` when this SDD is a reference exemplar — it demonstrates a profile shape rather than modelling a real product or provider relationship. Empty otherwise, which is the unmarked norm (absent in the manifest = a real SDD, no finding). From the manifest''s `exemplar:` field (sdd-manifest-schema 1.8.0). PROFILE-AGNOSTIC, unlike surface/packaging/application_archetype which are application-product-only — the first exemplar cohort found was integration-products. DERIVED, not authorable: this column and `integrations.exemplar` both come from the one manifest field, so they cannot disagree; two independently authored copies could, which is the failure mode the trait exists to remove. No builder branches on it — it is emitted to be filterable and nothing consumes it, because an implicit exclusion inside a rollup is much harder to remove than to add. Added in 2.46.0.'
+      description: "`true` when this SDD is a reference exemplar — it demonstrates a profile shape rather than modelling a real product or provider relationship. Empty otherwise, which is the unmarked norm (absent in the manifest = a real SDD, no finding). From the manifest's `exemplar:` field (sdd-manifest-schema 1.8.0). PROFILE-AGNOSTIC, unlike surface/packaging/application_archetype which are application-product-only — the first exemplar cohort found was integration-products. DERIVED, not authorable: this column and `integrations.exemplar` both come from the one manifest field, so they cannot disagree; two independently authored copies could, which is the failure mode the trait exists to remove. No builder branches on it — it is emitted to be filterable and nothing consumes it, because an implicit exclusion inside a rollup is much harder to remove than to add. Added in 2.46.0."
     - name: surface
       type: string
       nullable: true
-      description: 'ui | api (empty for non-application-product). Application-product surface trait from the manifest''s surface: field (M-ADR 0167, sdd-manifest-schema 1.2.0). Empty on non-application products. Added in 2.35.0.'
+      description: "ui | api (empty for non-application-product). Application-product surface trait from the manifest's surface: field (M-ADR 0167, sdd-manifest-schema 1.2.0). Empty on non-application products. Added in 2.35.0."
     - name: packaging
       type: string
       nullable: true
-      description: 'vendor-saas | self-operated (empty for non-application-product). Application-product packaging trait from the manifest''s packaging: field (M-ADR 0175, sdd-manifest-schema 1.7.0). `vendor-saas` marks a packaged-SaaS product — vendor-operated runtime (no own deployment evidence) and a vendor-versioned base capability set. Absent in the manifest resolves to `self-operated`, the unmarked norm. Per M-ADR 0175 §4 no builder may branch on this trait beyond evidence/deployment handling. Column position follows the M-ADR 0194 §3.1 canonical axis order (surface, packaging, application_archetype). Added in 2.41.0.'
+      description: "vendor-saas | self-operated (empty for non-application-product). Application-product packaging trait from the manifest's packaging: field (M-ADR 0175, sdd-manifest-schema 1.7.0). `vendor-saas` marks a packaged-SaaS product — vendor-operated runtime (no own deployment evidence) and a vendor-versioned base capability set. Absent in the manifest resolves to `self-operated`, the unmarked norm. Per M-ADR 0175 §4 no builder may branch on this trait beyond evidence/deployment handling. Column position follows the M-ADR 0194 §3.1 canonical axis order (surface, packaging, application_archetype). Added in 2.41.0."
     - name: application_archetype
       type: string
       nullable: true
-      description: 'Application-product shape classification from the manifest''s application_archetype: field (M-ADR 0191, sdd-manifest-schema 1.2.0). Resolved-enum over a tiered vocabulary (method: unclassified; reference-architecture bundle; adopter). Defaults to ''unclassified'' for application-product (with a coverage finding), empty for other profiles. Distinct from the M-ADR 0173 domain archetype and M-ADR 0169 openui archetype. Added in 2.35.0.'
+      description: "Application-product shape classification from the manifest's application_archetype: field (M-ADR 0191, sdd-manifest-schema 1.2.0). Resolved-enum over a tiered vocabulary (method: unclassified; reference-architecture bundle; adopter). Defaults to 'unclassified' for application-product (with a coverage finding), empty for other profiles. Distinct from the M-ADR 0173 domain archetype and M-ADR 0169 openui archetype. Added in 2.35.0."
     - name: synthesis_quality
       type: int
       nullable: true
-      description: 'DEPRECATED at 3.3.0, for removal at 4.0.0 — superseded by `quality_scores` (rubric_id `reverse-product-quality.product_synthesis_quality`). Score 0-10 from the product-synthesis rubric (reverse method only). WIRED in 2.47.0 from `orchestration/gate-registry/reverse-product-quality-scores.yaml` — the registry family at product granularity — via the SELF-PRODUCT rule: the unit whose `product_path` is ''.'' AND whose key equals the SDD''s sdd_id. Both conditions are required; product_path alone admits synthetic gate fixtures, key-matching alone admits covered sub-products. Backfill only: it fills an empty cell and never overwrites an emitted value. Empty on a forward estate by design — a forward-authored product has no reverse rubric score, and residue-based authoring signals deliberately do NOT write here (see status).'
+      description: "DEPRECATED at 3.3.0, for removal at 4.0.0 — superseded by `quality_scores` (rubric_id `reverse-product-quality.product_synthesis_quality`). Score 0-10 from the product-synthesis rubric (reverse method only). WIRED in 2.47.0 from `orchestration/gate-registry/reverse-product-quality-scores.yaml` — the registry family at product granularity — via the SELF-PRODUCT rule: the unit whose `product_path` is '.' AND whose key equals the SDD's sdd_id. Both conditions are required; product_path alone admits synthetic gate fixtures, key-matching alone admits covered sub-products. Backfill only: it fills an empty cell and never overwrites an emitted value. Empty on a forward estate by design — a forward-authored product has no reverse rubric score, and residue-based authoring signals deliberately do NOT write here (see status)."
     - name: synthesis_band
       type: string
       nullable: true
-      description: 'DEPRECATED at 3.3.0, for removal at 4.0.0 — superseded by `quality_scores.band`, which is UNBOUND because the vocabulary is per-rubric. This column''s closed set accepts only three of the SEVEN band values the reverse estate actually authors (measured 3.3.0: strong, working, weak, moderate, easy, hard, very-hard), silently emptying the rest. developing | working | strong — a CLOSED vocabulary; a band outside it is reported as a convention finding and the cell left empty rather than emitting a value no consumer can interpret. Wired in 2.47.0 alongside synthesis_quality.'
+      description: "DEPRECATED at 3.3.0, for removal at 4.0.0 — superseded by `quality_scores.band`, which is UNBOUND because the vocabulary is per-rubric. This column's closed set accepts only three of the SEVEN band values the reverse estate actually authors (measured 3.3.0: strong, working, weak, moderate, easy, hard, very-hard), silently emptying the rest. developing | working | strong — a CLOSED vocabulary; a band outside it is reported as a convention finding and the cell left empty rather than emitting a value no consumer can interpret. Wired in 2.47.0 alongside synthesis_quality."
     - name: last_assessed
       type: date
       nullable: true
@@ -385,7 +370,6 @@ catalogues:
       nullable: true
   applications:
     primary_key: id
-    description: Filtered view of products where profile = application-product.
     columns:
     - name: id
       type: string
@@ -405,7 +389,7 @@ catalogues:
     - name: category
       type: string
       nullable: true
-      description: 'Architectural classification per docs/method/methods/standards/product-category-taxonomy.md. Values: platform-root | platform-subsystem | application-product | integration-provider | integration-umbrella | support-repo. Determines whether the Product gets a c4_systems row.'
+      description: "Architectural classification per docs/method/methods/standards/product-category-taxonomy.md. Values: platform-root | platform-subsystem | application-product | integration-provider | integration-umbrella | support-repo. Determines whether the Product gets a c4_systems row."
     - name: doc_path
       type: string
       nullable: false
@@ -413,7 +397,7 @@ catalogues:
     - name: lifecycle
       type: string
       nullable: true
-      description: 'planned | active | deprecated (default active when empty). Owner-declared product lifecycle from the SDD manifest''s lifecycle: field (sdd-manifest-schema 1.1.0; `planned` added 1.9.0 / catalogue 2.47.0). `planned` = the product is real and intended but does not exist yet, which is the normal opening state of a forward-authored product — so a forward estate that has generated nothing should read `planned`, not the `active` the empty default implies. Distinct from status (documentation maturity): lifecycle is a fact about the PRODUCT, status about the DOCUMENT, and both can hold at once — a product can be reviewed AND deprecated, or planned AND thinly documented. Added in 2.22.0.'
+      description: "planned | active | deprecated (default active when empty). Owner-declared product lifecycle from the SDD manifest's lifecycle: field (sdd-manifest-schema 1.1.0; `planned` added 1.9.0 / catalogue 2.47.0). `planned` = the product is real and intended but does not exist yet, which is the normal opening state of a forward-authored product — so a forward estate that has generated nothing should read `planned`, not the `active` the empty default implies. Distinct from status (documentation maturity): lifecycle is a fact about the PRODUCT, status about the DOCUMENT, and both can hold at once — a product can be reviewed AND deprecated, or planned AND thinly documented. Added in 2.22.0."
     - name: deprecated_date
       type: date
       nullable: true
@@ -421,31 +405,31 @@ catalogues:
     - name: successor_sdd_id
       type: string
       nullable: true
-      description: 'For deprecated products: sdd_id of the superseding SDD. Same vocabulary as sdd_id/source_sdd_id (NOT products.id). Soft reference — the aggregator orphan-checks it against contributing sdd_ids ([finding] orphan when unresolved), never a hard FK: the successor may live outside the aggregation scope. Added in 2.22.0.'
+      description: "For deprecated products: sdd_id of the superseding SDD. Same vocabulary as sdd_id/source_sdd_id (NOT products.id). Soft reference — the aggregator orphan-checks it against contributing sdd_ids ([finding] orphan when unresolved), never a hard FK: the successor may live outside the aggregation scope. Added in 2.22.0."
     - name: exemplar
       type: string
       nullable: true
-      description: '`true` when this SDD is a reference exemplar — it demonstrates a profile shape rather than modelling a real product or provider relationship. Empty otherwise, which is the unmarked norm (absent in the manifest = a real SDD, no finding). From the manifest''s `exemplar:` field (sdd-manifest-schema 1.8.0). PROFILE-AGNOSTIC, unlike surface/packaging/application_archetype which are application-product-only — the first exemplar cohort found was integration-products. DERIVED, not authorable: this column and `integrations.exemplar` both come from the one manifest field, so they cannot disagree; two independently authored copies could, which is the failure mode the trait exists to remove. No builder branches on it — it is emitted to be filterable and nothing consumes it, because an implicit exclusion inside a rollup is much harder to remove than to add. Added in 2.46.0.'
+      description: "`true` when this SDD is a reference exemplar — it demonstrates a profile shape rather than modelling a real product or provider relationship. Empty otherwise, which is the unmarked norm (absent in the manifest = a real SDD, no finding). From the manifest's `exemplar:` field (sdd-manifest-schema 1.8.0). PROFILE-AGNOSTIC, unlike surface/packaging/application_archetype which are application-product-only — the first exemplar cohort found was integration-products. DERIVED, not authorable: this column and `integrations.exemplar` both come from the one manifest field, so they cannot disagree; two independently authored copies could, which is the failure mode the trait exists to remove. No builder branches on it — it is emitted to be filterable and nothing consumes it, because an implicit exclusion inside a rollup is much harder to remove than to add. Added in 2.46.0."
     - name: surface
       type: string
       nullable: true
-      description: 'ui | api (empty for non-application-product). Application-product surface trait from the manifest''s surface: field (M-ADR 0167, sdd-manifest-schema 1.2.0). Empty on non-application products. Added in 2.35.0.'
+      description: "ui | api (empty for non-application-product). Application-product surface trait from the manifest's surface: field (M-ADR 0167, sdd-manifest-schema 1.2.0). Empty on non-application products. Added in 2.35.0."
     - name: packaging
       type: string
       nullable: true
-      description: 'vendor-saas | self-operated (empty for non-application-product). Application-product packaging trait from the manifest''s packaging: field (M-ADR 0175, sdd-manifest-schema 1.7.0). `vendor-saas` marks a packaged-SaaS product — vendor-operated runtime (no own deployment evidence) and a vendor-versioned base capability set. Absent in the manifest resolves to `self-operated`, the unmarked norm. Per M-ADR 0175 §4 no builder may branch on this trait beyond evidence/deployment handling. Column position follows the M-ADR 0194 §3.1 canonical axis order (surface, packaging, application_archetype). Added in 2.41.0.'
+      description: "vendor-saas | self-operated (empty for non-application-product). Application-product packaging trait from the manifest's packaging: field (M-ADR 0175, sdd-manifest-schema 1.7.0). `vendor-saas` marks a packaged-SaaS product — vendor-operated runtime (no own deployment evidence) and a vendor-versioned base capability set. Absent in the manifest resolves to `self-operated`, the unmarked norm. Per M-ADR 0175 §4 no builder may branch on this trait beyond evidence/deployment handling. Column position follows the M-ADR 0194 §3.1 canonical axis order (surface, packaging, application_archetype). Added in 2.41.0."
     - name: application_archetype
       type: string
       nullable: true
-      description: 'Application-product shape classification from the manifest''s application_archetype: field (M-ADR 0191, sdd-manifest-schema 1.2.0). Resolved-enum over a tiered vocabulary (method: unclassified; reference-architecture bundle; adopter). Defaults to ''unclassified'' for application-product (with a coverage finding), empty for other profiles. Distinct from the M-ADR 0173 domain archetype and M-ADR 0169 openui archetype. Added in 2.35.0.'
+      description: "Application-product shape classification from the manifest's application_archetype: field (M-ADR 0191, sdd-manifest-schema 1.2.0). Resolved-enum over a tiered vocabulary (method: unclassified; reference-architecture bundle; adopter). Defaults to 'unclassified' for application-product (with a coverage finding), empty for other profiles. Distinct from the M-ADR 0173 domain archetype and M-ADR 0169 openui archetype. Added in 2.35.0."
     - name: synthesis_quality
       type: int
       nullable: true
-      description: 'DEPRECATED at 3.3.0, for removal at 4.0.0 — superseded by `quality_scores` (rubric_id `reverse-product-quality.product_synthesis_quality`). Score 0-10 from the product-synthesis rubric (reverse method only). WIRED in 2.47.0 from `orchestration/gate-registry/reverse-product-quality-scores.yaml` — the registry family at product granularity — via the SELF-PRODUCT rule: the unit whose `product_path` is ''.'' AND whose key equals the SDD''s sdd_id. Both conditions are required; product_path alone admits synthetic gate fixtures, key-matching alone admits covered sub-products. Backfill only: it fills an empty cell and never overwrites an emitted value. Empty on a forward estate by design — a forward-authored product has no reverse rubric score, and residue-based authoring signals deliberately do NOT write here (see status).'
+      description: "DEPRECATED at 3.3.0, for removal at 4.0.0 — superseded by `quality_scores` (rubric_id `reverse-product-quality.product_synthesis_quality`). Score 0-10 from the product-synthesis rubric (reverse method only). WIRED in 2.47.0 from `orchestration/gate-registry/reverse-product-quality-scores.yaml` — the registry family at product granularity — via the SELF-PRODUCT rule: the unit whose `product_path` is '.' AND whose key equals the SDD's sdd_id. Both conditions are required; product_path alone admits synthetic gate fixtures, key-matching alone admits covered sub-products. Backfill only: it fills an empty cell and never overwrites an emitted value. Empty on a forward estate by design — a forward-authored product has no reverse rubric score, and residue-based authoring signals deliberately do NOT write here (see status)."
     - name: synthesis_band
       type: string
       nullable: true
-      description: 'DEPRECATED at 3.3.0, for removal at 4.0.0 — superseded by `quality_scores.band`, which is UNBOUND because the vocabulary is per-rubric. This column''s closed set accepts only three of the SEVEN band values the reverse estate actually authors (measured 3.3.0: strong, working, weak, moderate, easy, hard, very-hard), silently emptying the rest. developing | working | strong — a CLOSED vocabulary; a band outside it is reported as a convention finding and the cell left empty rather than emitting a value no consumer can interpret. Wired in 2.47.0 alongside synthesis_quality.'
+      description: "DEPRECATED at 3.3.0, for removal at 4.0.0 — superseded by `quality_scores.band`, which is UNBOUND because the vocabulary is per-rubric. This column's closed set accepts only three of the SEVEN band values the reverse estate actually authors (measured 3.3.0: strong, working, weak, moderate, easy, hard, very-hard), silently emptying the rest. developing | working | strong — a CLOSED vocabulary; a band outside it is reported as a convention finding and the cell left empty rather than emitting a value no consumer can interpret. Wired in 2.47.0 alongside synthesis_quality."
     - name: last_assessed
       type: date
       nullable: true
@@ -464,13 +448,13 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: Filtered view of products where profile = application-product.
     foreign_keys:
     - column: domain_id
       references: domains.id
       nullable: true
   integrations:
     primary_key: id
-    description: Granular provider adapters. Each row is either (a) an integration-product SDD's own row (one per SDD; parent_product_id empty), or (b) a manifest-declared sub-integration of a multi-provider monolith (parent_product_id = umbrella SDD's id). Per M-ADR 0144 (schema 2.6.0), sub-integrations are declared via the optional `sub_integrations:` array in `integration-manifest.yaml`.
     columns:
     - name: id
       type: string
@@ -500,7 +484,7 @@ catalogues:
     - name: ingestion_pattern
       type: string
       nullable: true
-      description: 'Closed method-tier enum (event-stream-consume | webhook | socket-listen | poll) from the manifest''s SDD-level `ingestionPattern` — HOW the integration acquires data (M-ADR 0171 §4.2). SCALAR: §9.3''s multi-valued allowance was withdrawn in §10.5. Empty when undeclared or on an outbound-only integration. Empty on `sub_integrations` rows — the patterns are declared once at SDD level and are not per-provider. Added in 2.45.0.'
+      description: "Closed method-tier enum (event-stream-consume | webhook | socket-listen | poll) from the manifest's SDD-level `ingestionPattern` — HOW the integration acquires data (M-ADR 0171 §4.2). SCALAR: §9.3's multi-valued allowance was withdrawn in §10.5. Empty when undeclared or on an outbound-only integration. Empty on `sub_integrations` rows — the patterns are declared once at SDD level and are not per-provider. Added in 2.45.0."
     - name: invocation_pattern
       type: string
       nullable: true
@@ -512,7 +496,7 @@ catalogues:
     - name: exemplar
       type: string
       nullable: true
-      description: '`true` when the emitting SDD is a reference exemplar (demonstrates a profile shape rather than modelling a real provider relationship); empty otherwise. Derived from the SDD manifest''s `exemplar:` field (sdd-manifest-schema 1.8.0), same source as `products.exemplar` — neither column is independently authorable. Carried on `sub_integrations` rows too, INHERITED from the emitting SDD. That deliberately differs from `ingestion_pattern`/`invocation_pattern`, which are empty on sub rows, and the difference is the point: a pattern is a MECHANISM (how this integration acquires data), genuinely one per SDD, whereas `exemplar` is a REALITY STATUS that propagates to everything the SDD emits — if the SDD is a demonstration then every provider relationship it declares is a demonstration. Leaving sub rows empty would flag the umbrella and count its demonstration sub-providers as real, reproducing the rollup overcount this column exists to fix one level down. Do not normalise it to match the pattern columns. The trade accepted: a real SDD with one demonstration sub-provider is unexpressible — a state that should not exist. Added in 2.46.0.'
+      description: "`true` when the emitting SDD is a reference exemplar (demonstrates a profile shape rather than modelling a real provider relationship); empty otherwise. Derived from the SDD manifest's `exemplar:` field (sdd-manifest-schema 1.8.0), same source as `products.exemplar` — neither column is independently authorable. Carried on `sub_integrations` rows too, INHERITED from the emitting SDD. That deliberately differs from `ingestion_pattern`/`invocation_pattern`, which are empty on sub rows, and the difference is the point: a pattern is a MECHANISM (how this integration acquires data), genuinely one per SDD, whereas `exemplar` is a REALITY STATUS that propagates to everything the SDD emits — if the SDD is a demonstration then every provider relationship it declares is a demonstration. Leaving sub rows empty would flag the umbrella and count its demonstration sub-providers as real, reproducing the rollup overcount this column exists to fix one level down. Do not normalise it to match the pattern columns. The trade accepted: a real SDD with one demonstration sub-provider is unexpressible — a state that should not exist. Added in 2.46.0."
     - name: source_sdd_id
       type: string
       nullable: true
@@ -521,6 +505,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: Granular provider adapters. Each row is either (a) an integration-product SDD's own row (one per SDD; parent_product_id empty), or (b) a manifest-declared sub-integration of a multi-provider monolith (parent_product_id = umbrella SDD's id). Per M-ADR 0144 (schema 2.6.0), sub-integrations are declared via the optional `sub_integrations:` array in `integration-manifest.yaml`.
     foreign_keys:
     - column: domain_id
       references: domains.id
@@ -530,18 +515,11 @@ catalogues:
       nullable: true
   integration_component:
     primary_key: id
-    description: 'Integration-product edge (M-ADR 0171 §9, catalogued per §10.1): one row per component declared in the SDD''s `integration-manifest.yaml` `components:` array. A component is one of the integration''s component code repos (M-ADR 0106) — an integration SDD is a one-to-many spec→code unit — and the tier is the source of truth for the interaction pattern, with the SDD-level `ingestionPattern`/`invocationPattern` as its aggregate (§9.3).
-
-      Built per-SDD, integration-product only (other profiles emit headers-only). A component id is unique within its manifest and names an **interaction surface** — commonly one provider feed — which is NOT necessarily a deployable (§10.2). The optional `component_repo` carries an explicit code linkage; when declared it MUST resolve to a `repositories.id` or `services.id` of the same SDD, and a declared-but-unresolvable linkage is a **coverage finding, not a load failure**. `resolution` records the outcome inline, including `undeclared` for the normal feed-level case, so a consumer filters on it rather than inferring from a join miss.
-
-      The method deliberately does NOT enumerate `component_type` — that is the adopter''s own framework-role label (§9.1/§9.5), carried so an adopter''s role→pattern mapping stays machine-traceable. `transport`/`format`/`auth` are open strings for the same reason: they describe the wire, and the portable semantic is the pattern. Added in schema 2.43.0.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{integration_id}__{component_id}. A duplicate emits a divergence finding and is dropped — two components of one integration cannot share an id.'
+      description: "{integration_id}__{component_id}. A duplicate emits a divergence finding and is dropped — two components of one integration cannot share an id."
     - name: integration_id
       type: string
       nullable: false
@@ -553,7 +531,7 @@ catalogues:
     - name: component_repo
       type: string
       nullable: true
-      description: 'OPTIONAL explicit code linkage from `components[].componentRepo` — the deployable (repositories.id / services.id) that realises this component. Empty is the normal case for a feed-level component: the tier is at interaction-surface granularity, not deployable granularity, and the method does not require a component to name a deployable (M-ADR 0171 §10.2). When declared it MUST resolve, since a declared link is a positive assertion the method can check. Added in 2.44.0.'
+      description: "OPTIONAL explicit code linkage from `components[].componentRepo` — the deployable (repositories.id / services.id) that realises this component. Empty is the normal case for a feed-level component: the tier is at interaction-surface granularity, not deployable granularity, and the method does not require a component to name a deployable (M-ADR 0171 §10.2). When declared it MUST resolve, since a declared link is a positive assertion the method can check. Added in 2.44.0."
     - name: resolution
       type: string
       nullable: false
@@ -565,7 +543,7 @@ catalogues:
     - name: direction
       type: string
       nullable: true
-      description: 'inbound | outbound | bidirectional, from `dataFlow.direction`. Determines which pattern field is meaningful: inbound → ingestion_pattern, outbound → invocation_pattern, internal components declare neither (M-ADR 0171 §9.1).'
+      description: "inbound | outbound | bidirectional, from `dataFlow.direction`. Determines which pattern field is meaningful: inbound → ingestion_pattern, outbound → invocation_pattern, internal components declare neither (M-ADR 0171 §9.1)."
     - name: frequency
       type: string
       nullable: true
@@ -601,7 +579,7 @@ catalogues:
     - name: declared_in
       type: string
       nullable: false
-      description: 'components-array | component-manifest — WHICH of M-ADR 0171 §9.1''s two homes declared this component. Added in 2.49.0, when the second home became catalogued. Required because §10.1 states that any coverage reasoning MUST say which form it counts, and once one table holds both, a consumer cannot tell them apart: merging them without this recreates the reference-exemplar problem — well-formed rows that do not mean what a consumer assumes. Measured at the time of wiring: the array form was 15 components across 5 SDDs, the per-component form 86 across 21, and the two are DISJOINT (no id collision, no SDD using both). `resolution` also reads differently by form — for the array form `componentRepo` is an optional declaration (0 of 15 declared it); for the per-component form the containing `repos/<component>/` directory IS the repo, so linkage is structural rather than declared.'
+      description: "components-array | component-manifest — WHICH of M-ADR 0171 §9.1's two homes declared this component. Added in 2.49.0, when the second home became catalogued. Required because §10.1 states that any coverage reasoning MUST say which form it counts, and once one table holds both, a consumer cannot tell them apart: merging them without this recreates the reference-exemplar problem — well-formed rows that do not mean what a consumer assumes. Measured at the time of wiring: the array form was 15 components across 5 SDDs, the per-component form 86 across 21, and the two are DISJOINT (no id collision, no SDD using both). `resolution` also reads differently by form — for the array form `componentRepo` is an optional declaration (0 of 15 declared it); for the per-component form the containing `repos/<component>/` directory IS the repo, so linkage is structural rather than declared."
     - name: source_sdd_id
       type: string
       nullable: true
@@ -610,6 +588,10 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Integration-product edge (M-ADR 0171 §9, catalogued per §10.1): one row per component declared in the SDD's `integration-manifest.yaml` `components:` array. A component is one of the integration's component code repos (M-ADR 0106) — an integration SDD is a one-to-many spec→code unit — and the tier is the source of truth for the interaction pattern, with the SDD-level `ingestionPattern`/`invocationPattern` as its aggregate (§9.3).
+      Built per-SDD, integration-product only (other profiles emit headers-only). A component id is unique within its manifest and names an **interaction surface** — commonly one provider feed — which is NOT necessarily a deployable (§10.2). The optional `component_repo` carries an explicit code linkage; when declared it MUST resolve to a `repositories.id` or `services.id` of the same SDD, and a declared-but-unresolvable linkage is a **coverage finding, not a load failure**. `resolution` records the outcome inline, including `undeclared` for the normal feed-level case, so a consumer filters on it rather than inferring from a join miss.
+      The method deliberately does NOT enumerate `component_type` — that is the adopter's own framework-role label (§9.1/§9.5), carried so an adopter's role→pattern mapping stays machine-traceable. `transport`/`format`/`auth` are open strings for the same reason: they describe the wire, and the portable semantic is the pattern. Added in schema 2.43.0.
     foreign_keys:
     - column: integration_id
       references: integrations.id
@@ -631,7 +613,7 @@ catalogues:
     - name: domain_id
       type: string
       nullable: true
-      description: 'Domain slug for a domain-scoped ADR (docs/domains/<slug>/…); ''platform'' for a platform-scoped ADR (docs/platform/adr/), whose owner has that domain by construction; EMPTY for a method-scoped ADR (docs/method/adr/, docs/method/platform-adr/) — method ADRs are cross-cutting governance and belong to no domain. Nullable since 3.10.0 (M-ADR 0136 §4.3 amendment): before it, method ADRs were pinned to ''platform'' and dangled in every platform-root without a domain of that name.'
+      description: "Domain slug for a domain-scoped ADR (docs/domains/<slug>/…); 'platform' for a platform-scoped ADR (docs/platform/adr/), whose owner has that domain by construction; EMPTY for a method-scoped ADR (docs/method/adr/, docs/method/platform-adr/) — method ADRs are cross-cutting governance and belong to no domain. Nullable since 3.10.0 (M-ADR 0136 §4.3 amendment): before it, method ADRs were pinned to 'platform' and dangled in every platform-root without a domain of that name."
     - name: decision_date
       type: date
       nullable: true
@@ -670,7 +652,7 @@ catalogues:
     - name: id
       type: string
       nullable: false
-      description: 'Slug: {domain}-{term-slug} for uniqueness.'
+      description: "Slug: {domain}-{term-slug} for uniqueness."
     - name: term
       type: string
       nullable: false
@@ -688,7 +670,7 @@ catalogues:
     - name: aliases
       type: string
       nullable: true
-      description: ''';''-separated list.'
+      description: "';'-separated list."
     - name: evidence
       type: string
       nullable: true
@@ -712,12 +694,11 @@ catalogues:
       nullable: true
   glossary_xref:
     primary_key: id
-    description: 'Edge: cross-domain glossary relationships from glossary-alignment-manifest.yaml. Per M-ADR 0158, four walkers ingest into this catalogue: (a) forward declared pair-form {source, target} entries under aliases/conflicts, (b) reverse-method cross_domain_terms (emits references edges per referencer→owner), (c) reverse-method multi-domain conflicts (pair-wise expansion across domains[]), (d) forward-method supersedes (status: superseded entries with superseded_by back-link).'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Composite: {source_id}__{relation}__{target_id}.'
+      description: "Composite: {source_id}__{relation}__{target_id}."
     - name: source_id
       type: string
       nullable: false
@@ -728,6 +709,7 @@ catalogues:
       type: string
       nullable: false
       description: alias-of | conflicts-with | references | supersedes (extended in schema 2.12.0 per M-ADR 0158).
+    description: "Edge: cross-domain glossary relationships from glossary-alignment-manifest.yaml. Per M-ADR 0158, four walkers ingest into this catalogue: (a) forward declared pair-form {source, target} entries under aliases/conflicts, (b) reverse-method cross_domain_terms (emits references edges per referencer→owner), (c) reverse-method multi-domain conflicts (pair-wise expansion across domains[]), (d) forward-method supersedes (status: superseded entries with superseded_by back-link)."
     foreign_keys:
     - column: source_id
       references: glossary_items.id
@@ -737,12 +719,11 @@ catalogues:
       nullable: false
   entity_glossary:
     primary_key: id
-    description: 'Edge: data-model entity → canonical glossary term. Added in schema 2.12.0 per M-ADR 0158. Source: glossary-alignment-manifest.yaml `models[].entities[]` with status ∈ {aligned, matched_direct} and non-empty glossary_term. PK derives from (domain, entity_name, glossary_item) so same-domain multi-diagram entries collapse to one row; cross-domain entries (e.g. platform-wide conceptual model + domain-specific model) emit one row per domain — legitimate cross-level cataloguing.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Composite: {domain_id}__{entity_name_slug}__{glossary_item_id}.'
+      description: "Composite: {domain_id}__{entity_name_slug}__{glossary_item_id}."
     - name: domain_id
       type: string
       nullable: false
@@ -768,6 +749,7 @@ catalogues:
       type: string
       nullable: true
       description: The data-model entity this glossary mapping is about — an entities.id. The edge was always emitted per (domain, entity, glossary_term) and this end was missing from its keys (found at M-ADR 0210 flip 2; added at 3.9.0). Nullable until every builder populates it.
+    description: "Edge: data-model entity → canonical glossary term. Added in schema 2.12.0 per M-ADR 0158. Source: glossary-alignment-manifest.yaml `models[].entities[]` with status ∈ {aligned, matched_direct} and non-empty glossary_term. PK derives from (domain, entity_name, glossary_item) so same-domain multi-diagram entries collapse to one row; cross-domain entries (e.g. platform-wide conceptual model + domain-specific model) emit one row per domain — legitimate cross-level cataloguing."
     foreign_keys:
     - column: domain_id
       references: domains.id
@@ -879,7 +861,7 @@ catalogues:
     - name: status
       type: string
       nullable: false
-      description: 'Capability LIFECYCLE phase — this column carries ONE axis and the reader may rely on that. active | planned | exploration | deprecated. Default ''active''. History, because the shape of the mistake is the useful part: the prior three-member set (active|planned|deprecated) could not express what estates authored, so 3.5.0 widened it to six on measured evidence — 44 of one estate''s 78 manifests were outside it (exploration 26, placeholder 11, detailed-pre-lock 6, first-draft 1), each recurring value varying WITHIN a domain, which is the ruled discriminator for a genuine phase over an authoring convention. But 3.6.0 RETRACTED `placeholder` and `detailed-pre-lock`: per M-ADR 0201 §1 those are rungs on the SPEC-AUTHORING ladder (`placeholder | first-draft | detailed-pre-lock`, plus §4.1''s `reverse-derived`), declared in each spec''s own `**Status:**` header and gated there by the spec-lifecycle gate. Admitting them here made one column carry two orthogonal axes, so a reader could not tell whether `placeholder` described the capability or its document. **Where the other axis lives: the spec header. Do not re-import it here.** `exploration` stays and is NOT authoring vocabulary — it is absent from 0201''s ladder, has M-ADR 0089''s workflow and named gates behind it, and describes the capability rather than its spec; a capability declaring it must carry a populated `traceability.exploration` block, and one that does not is a loud contradiction (validate-traceability enforces this; measured 0 of 26 violations). ⚠ A rule this column deliberately does NOT carry: `placeholder`''s. The obvious one (no authored features) was MEASURED FALSE — 4 of 11 carried features, one of them 9 — and the deeper reason no rule fit is that `placeholder` was never making a claim about the capability at all. That unwritable rule was the first symptom of the axis error, before anyone had named it. ⚠ DELIBERATELY NOT BOUND via column_enums, and this is staged rather than permanent: binding carries hard-fail teeth, and at 3.5.0 one out-of-vocabulary row remains (forward estate, `first-draft`, n=1, referred to that estate; the reverse estate measures ZERO across 180 manifests). An out-of-vocabulary value is CARRIED, not emptied and not rejected, and is reported as a convention finding by validate-traceability — nullable stays false and no cell is ever emptied, so the empty-means-unauthored-or-rejected ambiguity of the products.synthesis_band / quality_scores.gate precedents does not arise here. Bind only once that count is ZERO at both estates; binding a set not proven to cover what estates author is how synthesis_band earned its deprecation. On drift and enforcement, stated with its confound rather than as a slogan: the enforced sibling `contracts.status` drifted 1.2% (2 of 172) while this unenforced field drifted 56% (44 of 78) at the SAME estate — but the other estate''s copy of this same unenforced field drifted 0% of 180, so enforcement is not the only variable. The difference is authoring shape: the forward estate hand-authors per capability across 13 domains and explores vocabulary doing it, while the reverse estate''s manifests come from one largely uniform extraction process. That uniformity is itself the phase-vs-convention discriminator firing — a value uniform across a whole estate is tracking the process that wrote it.'
+      description: "Capability LIFECYCLE phase — this column carries ONE axis and the reader may rely on that. active | planned | exploration | deprecated. Default 'active'. History, because the shape of the mistake is the useful part: the prior three-member set (active|planned|deprecated) could not express what estates authored, so 3.5.0 widened it to six on measured evidence — 44 of one estate's 78 manifests were outside it (exploration 26, placeholder 11, detailed-pre-lock 6, first-draft 1), each recurring value varying WITHIN a domain, which is the ruled discriminator for a genuine phase over an authoring convention. But 3.6.0 RETRACTED `placeholder` and `detailed-pre-lock`: per M-ADR 0201 §1 those are rungs on the SPEC-AUTHORING ladder (`placeholder | first-draft | detailed-pre-lock`, plus §4.1's `reverse-derived`), declared in each spec's own `**Status:**` header and gated there by the spec-lifecycle gate. Admitting them here made one column carry two orthogonal axes, so a reader could not tell whether `placeholder` described the capability or its document. **Where the other axis lives: the spec header. Do not re-import it here.** `exploration` stays and is NOT authoring vocabulary — it is absent from 0201's ladder, has M-ADR 0089's workflow and named gates behind it, and describes the capability rather than its spec; a capability declaring it must carry a populated `traceability.exploration` block, and one that does not is a loud contradiction (validate-traceability enforces this; measured 0 of 26 violations). ⚠ A rule this column deliberately does NOT carry: `placeholder`'s. The obvious one (no authored features) was MEASURED FALSE — 4 of 11 carried features, one of them 9 — and the deeper reason no rule fit is that `placeholder` was never making a claim about the capability at all. That unwritable rule was the first symptom of the axis error, before anyone had named it. ⚠ DELIBERATELY NOT BOUND via column_enums, and this is staged rather than permanent: binding carries hard-fail teeth, and at 3.5.0 one out-of-vocabulary row remains (forward estate, `first-draft`, n=1, referred to that estate; the reverse estate measures ZERO across 180 manifests). An out-of-vocabulary value is CARRIED, not emptied and not rejected, and is reported as a convention finding by validate-traceability — nullable stays false and no cell is ever emptied, so the empty-means-unauthored-or-rejected ambiguity of the products.synthesis_band / quality_scores.gate precedents does not arise here. Bind only once that count is ZERO at both estates; binding a set not proven to cover what estates author is how synthesis_band earned its deprecation. On drift and enforcement, stated with its confound rather than as a slogan: the enforced sibling `contracts.status` drifted 1.2% (2 of 172) while this unenforced field drifted 56% (44 of 78) at the SAME estate — but the other estate's copy of this same unenforced field drifted 0% of 180, so enforcement is not the only variable. The difference is authoring shape: the forward estate hand-authors per capability across 13 domains and explores vocabulary doing it, while the reverse estate's manifests come from one largely uniform extraction process. That uniformity is itself the phase-vs-convention discriminator firing — a value uniform across a whole estate is tracking the process that wrote it."
     - name: spec_path
       type: string
       nullable: true
@@ -887,7 +869,7 @@ catalogues:
     - name: contract_provenance
       type: string
       nullable: true
-      description: 'How this capability''s declared contract SET was produced, from `traceability.contracts.provenance`. hand-authored | reverse-extracted | generated — the vocabulary the method already ships for `authoring-mode`, reused deliberately so provenance has one vocabulary and not two. Empty means undeclared, and undeclared reads as `hand-authored` by convention. Added at 3.5.0. ⚠ STRICTLY ORTHOGONAL to the contract-set maturity ladder (`traceability.contracts.status`: planned | provisional | partial | complete | locked | none): provenance never constrains status and status never constrains provenance, and `reverse-extracted` + `complete` is the legitimate pair that motivated the field. Evidence: 2 reverse-estate manifests had written `reverse-extracted` INTO contracts.status, where it is invalid, because a complete reverse-derived contract surface had no way to say both true things at once and the author picked the provenance one. A rule here that constrained maturity would re-create exactly that defect. ⚠ Note the asymmetry this column exposes and does not fix: the maturity ladder it is orthogonal to has NO catalogue column at all — `traceability.contracts.status` is validator-enforced but uncatalogued, so it is queryable by no consumer. That is the authored-but-uncatalogued class (a block with no column has no automated reader, so nothing can notice when it is absent or wrong); this column is given one precisely so the provenance half does not join it. Giving the ladder a column is a candidate follow-on, not done here.'
+      description: "How this capability's declared contract SET was produced, from `traceability.contracts.provenance`. hand-authored | reverse-extracted | generated — the vocabulary the method already ships for `authoring-mode`, reused deliberately so provenance has one vocabulary and not two. Empty means undeclared, and undeclared reads as `hand-authored` by convention. Added at 3.5.0. ⚠ STRICTLY ORTHOGONAL to the contract-set maturity ladder (`traceability.contracts.status`: planned | provisional | partial | complete | locked | none): provenance never constrains status and status never constrains provenance, and `reverse-extracted` + `complete` is the legitimate pair that motivated the field. Evidence: 2 reverse-estate manifests had written `reverse-extracted` INTO contracts.status, where it is invalid, because a complete reverse-derived contract surface had no way to say both true things at once and the author picked the provenance one. A rule here that constrained maturity would re-create exactly that defect. ⚠ Note the asymmetry this column exposes and does not fix: the maturity ladder it is orthogonal to has NO catalogue column at all — `traceability.contracts.status` is validator-enforced but uncatalogued, so it is queryable by no consumer. That is the authored-but-uncatalogued class (a block with no column has no automated reader, so nothing can notice when it is absent or wrong); this column is given one precisely so the provenance half does not join it. Giving the ladder a column is a candidate follow-on, not done here."
     - name: source
       type: string
       nullable: false
@@ -903,7 +885,7 @@ catalogues:
     - name: slice_scope
       type: string
       nullable: true
-      description: 'Per-slice marker when one capability legitimately covers multiple app groups or data subsets (e.g. a compliance capability spanning several regulated-fleet sub-groups). Same capability_id may appear across multiple rows when sliced; row identity is then `(id, slice_scope)`. Empty when the capability is not sliced. Per-slice AC numbering convention: AC1-ACN unsuffixed for the first slice; subsequent slices use AC numbering suffixed by slice. See `docs/method/methods/reverse/rubrics/reverse-platform-evidence-quality.md` §`slice_scope:` and `docs/method/methods/capability-spec-template.md` Guideline 9. Added in schema 2.9.0.'
+      description: "Per-slice marker when one capability legitimately covers multiple app groups or data subsets (e.g. a compliance capability spanning several regulated-fleet sub-groups). Same capability_id may appear across multiple rows when sliced; row identity is then `(id, slice_scope)`. Empty when the capability is not sliced. Per-slice AC numbering convention: AC1-ACN unsuffixed for the first slice; subsequent slices use AC numbering suffixed by slice. See `docs/method/methods/reverse/rubrics/reverse-platform-evidence-quality.md` §`slice_scope:` and `docs/method/methods/capability-spec-template.md` Guideline 9. Added in schema 2.9.0."
     - name: source_sdd_id
       type: string
       nullable: true
@@ -924,14 +906,11 @@ catalogues:
       nullable: true
   feature_groups:
     primary_key: id
-    description: 'Hierarchical grouping for features. First-class entity per resolution of adopt-canonical-catalogue-builder.md §7.2 — replaces the previous reverse-only synthetic `feature-tree-group` rows in features.csv. Both forward and reverse can use feature_groups: forward application-product SDDs whose `feature-tree.md` has H2/H3 structure, reverse SDDs whose extracted feature trees are inherently hierarchical, and any SDD that promotes groups to first-class with authored metadata. Groups can nest via `parent_group_id`.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{product_id|capability_id}-group-{slug}[-{nested-slug}].'
+      description: "{product_id|capability_id}-group-{slug}[-{nested-slug}]."
     - name: name
       type: string
       nullable: false
@@ -964,6 +943,8 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Hierarchical grouping for features. First-class entity per resolution of adopt-canonical-catalogue-builder.md §7.2 — replaces the previous reverse-only synthetic `feature-tree-group` rows in features.csv. Both forward and reverse can use feature_groups: forward application-product SDDs whose `feature-tree.md` has H2/H3 structure, reverse SDDs whose extracted feature trees are inherently hierarchical, and any SDD that promotes groups to first-class with authored metadata. Groups can nest via `parent_group_id`.
     foreign_keys:
     - column: product_id
       references: products.id
@@ -980,7 +961,7 @@ catalogues:
     - name: id
       type: string
       nullable: false
-      description: '{product_id|capability_id}-{feature-slug}.'
+      description: "{product_id|capability_id}-{feature-slug}."
     - name: name
       type: string
       nullable: false
@@ -1005,7 +986,7 @@ catalogues:
     - name: maturity
       type: string
       nullable: true
-      description: 'Standard: working | provisional | unknown | absent. Ecosystem-specific values may be added with parser awareness.'
+      description: "Standard: working | provisional | unknown | absent. Ecosystem-specific values may be added with parser awareness."
     - name: status
       type: string
       nullable: false
@@ -1013,7 +994,7 @@ catalogues:
     - name: source
       type: string
       nullable: false
-      description: 'feature-tree | feature-set | capability-spec | feature-spec | feature-grounding. NOTE: feature-tree-group source removed in 1.3.0 — groups are now first-class in feature_groups.csv. As of schema 2.2.0, source: feature-tree is emitted by the canonical builder for rows derived from feature-tree.md bullets. As of schema 2.5.0, source: feature-grounding is emitted for rows derived from `docs/domains/<dom>/design/<capability>/feature-grounding.md` markdown tables (per M-ADR 0143). As of schema 2.7.0, source: capability-spec is emitted by the canonical builder for rows derived from `## Feature Grounding (code-path trace)` tables in `docs/domains/<dom>/product/<capability>.md` capability spec markdown (per M-ADR 0145). Feature-grounding and capability-spec rows are both capability-owned: product_id is empty; capability_id resolves from the file path.'
+      description: "feature-tree | feature-set | capability-spec | feature-spec | feature-grounding. NOTE: feature-tree-group source removed in 1.3.0 — groups are now first-class in feature_groups.csv. As of schema 2.2.0, source: feature-tree is emitted by the canonical builder for rows derived from feature-tree.md bullets. As of schema 2.5.0, source: feature-grounding is emitted for rows derived from `docs/domains/<dom>/design/<capability>/feature-grounding.md` markdown tables (per M-ADR 0143). As of schema 2.7.0, source: capability-spec is emitted by the canonical builder for rows derived from `## Feature Grounding (code-path trace)` tables in `docs/domains/<dom>/product/<capability>.md` capability spec markdown (per M-ADR 0145). Feature-grounding and capability-spec rows are both capability-owned: product_id is empty; capability_id resolves from the file path."
     - name: runway
       type: string
       nullable: true
@@ -1045,7 +1026,7 @@ catalogues:
     - name: id
       type: string
       nullable: false
-      description: '{product_id}-{persona-slug}.'
+      description: "{product_id}-{persona-slug}."
     - name: name
       type: string
       nullable: false
@@ -1076,7 +1057,7 @@ catalogues:
     - name: id
       type: string
       nullable: false
-      description: '{product_id}-{journey-slug}.'
+      description: "{product_id}-{journey-slug}."
     - name: name
       type: string
       nullable: false
@@ -1114,7 +1095,7 @@ catalogues:
     - name: id
       type: string
       nullable: false
-      description: '{domain}-{stem}-{kind} — the kind component joined the id at schema 3.0.0 (M-ADR 0203 §4.4), ending the kindless collision class where one service published as two contract families (openapi + proto) minted one id (measured cost: 1 row + 2 edges permanently unrepresentable, plus legitimate shared-contract citation flagged as divergence). Mechanical migration: new id = old id + ''-'' + kind; `sdd-cli catalogue migration-map` emits the pairs, and authored alias targets (M-ADR 0147) re-key automatically during the cut window.'
+      description: "{domain}-{stem}-{kind} — the kind component joined the id at schema 3.0.0 (M-ADR 0203 §4.4), ending the kindless collision class where one service published as two contract families (openapi + proto) minted one id (measured cost: 1 row + 2 edges permanently unrepresentable, plus legitimate shared-contract citation flagged as divergence). Mechanical migration: new id = old id + '-' + kind; `sdd-cli catalogue migration-map` emits the pairs, and authored alias targets (M-ADR 0147) re-key automatically during the cut window."
     - name: name
       type: string
       nullable: false
@@ -1177,7 +1158,6 @@ catalogues:
       nullable: true
   events:
     primary_key: id
-    description: 'Asynchronous messages. Cross-domain events (e.g. shared envelopes) leave domain_id empty. Per M-ADR 0156 (multi-source ingestion, schema 2.12.0): forward-method canonical source is `contracts/avro/*.avsc` files; reverse-method canonical source is `docs/domains/{domain}/contracts/events/event-catalog.yaml`. YAML wins on name/domain/publisher/transport/consumers; avsc augments schema_path/version. Both paths run and merge by id slug.'
     columns:
     - name: id
       type: string
@@ -1194,11 +1174,11 @@ catalogues:
     - name: transport
       type: string
       nullable: true
-      description: 'Open string per M-ADR 0156. Recommended values: kafka | sns | sqs | kinesis | eventbridge | mongodb-change-stream | nats | activemq | rabbitmq | jms | other. Values outside the recommended set emit [finding] convention.'
+      description: "Open string per M-ADR 0156. Recommended values: kafka | sns | sqs | kinesis | eventbridge | mongodb-change-stream | nats | activemq | rabbitmq | jms | other. Values outside the recommended set emit [finding] convention."
     - name: schema_path
       type: string
       nullable: true
-      description: 'Path to event schema (Avro .avsc or JSON-Schema .json/.schema.json). Nullable — leave empty for loosely-typed events (e.g. ActiveMQ JMS, NATS with payload_schema: {type: object}). Per M-ADR 0156.'
+      description: "Path to event schema (Avro .avsc or JSON-Schema .json/.schema.json). Nullable — leave empty for loosely-typed events (e.g. ActiveMQ JMS, NATS with payload_schema: {type: object}). Per M-ADR 0156."
     - name: version
       type: string
       nullable: true
@@ -1214,6 +1194,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Asynchronous messages. Cross-domain events (e.g. shared envelopes) leave domain_id empty. Per M-ADR 0156 (multi-source ingestion, schema 2.12.0): forward-method canonical source is `contracts/avro/*.avsc` files; reverse-method canonical source is `docs/domains/{domain}/contracts/events/event-catalog.yaml`. YAML wins on name/domain/publisher/transport/consumers; avsc augments schema_path/version. Both paths run and merge by id slug."
     foreign_keys:
     - column: publisher_service_id
       references: services.id
@@ -1234,7 +1215,7 @@ catalogues:
     - name: product_id
       type: string
       nullable: true
-      description: 'Owning product, when the system corresponds to one. Nullable: every product is a system, but not every system is a product (external/SaaS systems have no owning product). Architectural products only (per category taxonomy). Relaxed to nullable in schema 2.11.0.'
+      description: "Owning product, when the system corresponds to one. Nullable: every product is a system, but not every system is a product (external/SaaS systems have no owning product). Architectural products only (per category taxonomy). Relaxed to nullable in schema 2.11.0."
     - name: kind
       type: string
       nullable: false
@@ -1262,14 +1243,11 @@ catalogues:
       kind: enums.c4_system_kind
   c4_containers:
     primary_key: id
-    description: 'C4 L2. Each container belongs to exactly one C4 system. `domain_id` is a denormalised organisational tag, not a C4-structural attribute — multi-domain ecosystems use it for filtering/reporting. `service_id` is the optional "may represent" link to a runtime service when the container is a deployable application.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{system_id}-{container-slug}.'
+      description: "{system_id}-{container-slug}."
     - name: name
       type: string
       nullable: false
@@ -1288,7 +1266,7 @@ catalogues:
     - name: type
       type: string
       nullable: true
-      description: 'Canonical C4 container kind — bound to enums.c4_container_type (Application | Data Store) since 3.0.0, hard-fail (M-ADR 0203 §4.1 completing M-ADR 0155). The 2.x legacy values are removed: External System boxes belong in c4_external_systems; running infrastructure retypes; deployment infrastructure leaves the catalogue.'
+      description: "Canonical C4 container kind — bound to enums.c4_container_type (Application | Data Store) since 3.0.0, hard-fail (M-ADR 0203 §4.1 completing M-ADR 0155). The 2.x legacy values are removed: External System boxes belong in c4_external_systems; running infrastructure retypes; deployment infrastructure leaves the catalogue."
     - name: technology
       type: string
       nullable: true
@@ -1303,6 +1281,8 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      C4 L2. Each container belongs to exactly one C4 system. `domain_id` is a denormalised organisational tag, not a C4-structural attribute — multi-domain ecosystems use it for filtering/reporting. `service_id` is the optional "may represent" link to a runtime service when the container is a deployable application.
     foreign_keys:
     - column: system_id
       references: c4_systems.id
@@ -1317,14 +1297,11 @@ catalogues:
       type: enums.c4_container_type
   c4_components:
     primary_key: id
-    description: 'C4 L3. Each component belongs to exactly one C4 container. `service_id` is denormalised from `c4_containers.service_id` for query convenience — populated when the parent container represents a runtime service.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{container_id}-{component-slug}.'
+      description: "{container_id}-{component-slug}."
     - name: name
       type: string
       nullable: false
@@ -1335,7 +1312,7 @@ catalogues:
     - name: service_id
       type: string
       nullable: true
-      description: 'Denormalised: the service the parent container represents, when applicable.'
+      description: "Denormalised: the service the parent container represents, when applicable."
     - name: path
       type: string
       nullable: true
@@ -1350,6 +1327,8 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      C4 L3. Each component belongs to exactly one C4 container. `service_id` is denormalised from `c4_containers.service_id` for query convenience — populated when the parent container represents a runtime service.
     foreign_keys:
     - column: container_id
       references: c4_containers.id
@@ -1359,9 +1338,6 @@ catalogues:
       nullable: true
   c4_external_systems:
     primary_key: id
-    description: 'C4 external software systems — peer systems at the L1 context level that the ecosystem integrates with but does not own (per M-ADR 0155). Rendered `System_Ext(...)` on L1/L2 diagrams. NOT a c4_container (external systems are not inside your system) and NOT a c4_system (they have no owning Product). External systems are inherently shared references: the same external system may be declared by multiple SDDs, so the aggregator dedups identical rows by PK rather than failing on duplicate (the one narrowly-scoped exception to M-ADR 0134''s duplicate-PK rule); conflicting attributes on the same id surface as a `convention` finding.
-
-      '
     columns:
     - name: id
       type: string
@@ -1386,7 +1362,7 @@ catalogues:
     - name: source_scope
       type: string
       nullable: true
-      description: 'Scope of the first-seen declaration: l1 (context diagram) or l2 (container diagram — scope-relative per M-ADR 0189 §4.1). Added 2.30.0.'
+      description: "Scope of the first-seen declaration: l1 (context diagram) or l2 (container diagram — scope-relative per M-ADR 0189 §4.1). Added 2.30.0."
     - name: source_sdd_id
       type: string
       nullable: true
@@ -1395,6 +1371,8 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      C4 external software systems — peer systems at the L1 context level that the ecosystem integrates with but does not own (per M-ADR 0155). Rendered `System_Ext(...)` on L1/L2 diagrams. NOT a c4_container (external systems are not inside your system) and NOT a c4_system (they have no owning Product). External systems are inherently shared references: the same external system may be declared by multiple SDDs, so the aggregator dedups identical rows by PK rather than failing on duplicate (the one narrowly-scoped exception to M-ADR 0134's duplicate-PK rule); conflicting attributes on the same id surface as a `convention` finding.
   repositories:
     primary_key: id
     columns:
@@ -1446,7 +1424,7 @@ catalogues:
     - name: languages
       type: string
       nullable: true
-      description: ''';''-separated.'
+      description: "';'-separated."
     - name: doc_path
       type: string
       nullable: false
@@ -1469,12 +1447,11 @@ catalogues:
       component_type: enums.service_type
   domain_models:
     primary_key: id
-    description: 'Per-domain ER diagram modelling the domain''s aggregates, entities, and domain events. Platform-profile only — application and integration profiles emit headers-only. Forward source: `traceability.domain_model.path` in capability traceability manifests. Reverse source: file-system scan of `docs/domains/*/architecture/data-model.mermaid.md`. Added in schema 2.4.0; see M-ADR 0142.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{domain_id}-data-model.'
+      description: "{domain_id}-data-model."
     - name: name
       type: string
       nullable: false
@@ -1501,18 +1478,18 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Per-domain ER diagram modelling the domain's aggregates, entities, and domain events. Platform-profile only — application and integration profiles emit headers-only. Forward source: `traceability.domain_model.path` in capability traceability manifests. Reverse source: file-system scan of `docs/domains/*/architecture/data-model.mermaid.md`. Added in schema 2.4.0; see M-ADR 0142."
     foreign_keys:
     - column: domain_id
       references: domains.id
       nullable: false
   entities:
     primary_key: id
-    description: 'Data-model entity (a structural realisation of a concept inside a domain''s data model). Distinct from glossary_items (vocabulary-level) and from domain_models (file-level). Added in schema 2.13.0 per M-ADR 0159. Forward source: `models[].entities[]` in glossary-alignment-manifest.yaml. Reverse source: `EntityName { ... }` declarations inside `erDiagram` fences in `docs/domains/{domain}/architecture/data-model.mermaid.md`. PK uses an entity-aware slug that normalises across UPPER_SNAKE and PascalCase authoring styles.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Slugged PK: {domain_id}-{entitySlug(name)}. For manifest-sourced rows with domain=platform-wide, the leading domain segment is empty (`-{entitySlug(name)}`) and the row carries a [finding] convention.'
+      description: "Slugged PK: {domain_id}-{entitySlug(name)}. For manifest-sourced rows with domain=platform-wide, the leading domain segment is empty (`-{entitySlug(name)}`) and the row carries a [finding] convention."
     - name: name
       type: string
       nullable: false
@@ -1528,7 +1505,7 @@ catalogues:
     - name: persistence_kind
       type: string
       nullable: true
-      description: 'Open string; recommended values: relational-table | document-collection | event-payload | dto | view | other. Values outside the recommended set fire `[finding] convention`.'
+      description: "Open string; recommended values: relational-table | document-collection | event-payload | dto | view | other. Values outside the recommended set fire `[finding] convention`."
     - name: context
       type: string
       nullable: true
@@ -1553,6 +1530,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Data-model entity (a structural realisation of a concept inside a domain's data model). Distinct from glossary_items (vocabulary-level) and from domain_models (file-level). Added in schema 2.13.0 per M-ADR 0159. Forward source: `models[].entities[]` in glossary-alignment-manifest.yaml. Reverse source: `EntityName { ... }` declarations inside `erDiagram` fences in `docs/domains/{domain}/architecture/data-model.mermaid.md`. PK uses an entity-aware slug that normalises across UPPER_SNAKE and PascalCase authoring styles."
     foreign_keys:
     - column: domain_id
       references: domains.id
@@ -1565,7 +1543,6 @@ catalogues:
       nullable: true
   repo_capability:
     primary_key: id
-    description: 'Edge: repo contributes to capability. Forward-declared via repo-config `capabilities[]` (M-ADR 0188 §6.1) or the legacy multi-purpose `additional_context[]`; reverse-derived via capability_service ⋈ services.primary_repo_id and capability_feature ⋈ feature_repo.'
     columns:
     - name: id
       type: string
@@ -1576,6 +1553,7 @@ catalogues:
     - name: capability_id
       type: string
       nullable: false
+    description: "Edge: repo contributes to capability. Forward-declared via repo-config `capabilities[]` (M-ADR 0188 §6.1) or the legacy multi-purpose `additional_context[]`; reverse-derived via capability_service ⋈ services.primary_repo_id and capability_feature ⋈ feature_repo."
     foreign_keys:
     - column: repo_id
       references: repositories.id
@@ -1585,13 +1563,6 @@ catalogues:
       nullable: false
   repo_capability_exemption:
     primary_key: id
-    description: 'A repository''s declared, reasoned statement that it bears no product capability (M-ADR 0188 §4.3). Emitted from the repo-config `capability_exemption:` block.
-
-      This is deliberately a catalogue row rather than an inert YAML aside. An exemption is a modelling assertion and belongs in the model: it is then queryable at the aggregate tier, reviewable in the same surface as the capabilities it stands in for, and countable — so that a reviewer watching the exemption population grow can see it happen. Never net exemptions off against orphans in a metric.
-
-      The invariant it participates in (M-ADR 0188 §4.1): every `repositories` row must resolve, either by carrying a `repo_capability` edge or by declaring an exemption here. A row satisfying both is a declaration conflict, reported as a `divergence` finding.
-
-      '
     columns:
     - name: id
       type: string
@@ -1606,6 +1577,10 @@ catalogues:
       type: string
       nullable: false
       description: Mandatory, non-empty. The reason code makes exemptions countable; the note makes them reviewable. A row with an empty note is dropped with a `convention` finding.
+    description: |
+      A repository's declared, reasoned statement that it bears no product capability (M-ADR 0188 §4.3). Emitted from the repo-config `capability_exemption:` block.
+      This is deliberately a catalogue row rather than an inert YAML aside. An exemption is a modelling assertion and belongs in the model: it is then queryable at the aggregate tier, reviewable in the same surface as the capabilities it stands in for, and countable — so that a reviewer watching the exemption population grow can see it happen. Never net exemptions off against orphans in a metric.
+      The invariant it participates in (M-ADR 0188 §4.1): every `repositories` row must resolve, either by carrying a `repo_capability` edge or by declaring an exemption here. A row satisfying both is a declaration conflict, reported as a `divergence` finding.
     foreign_keys:
     - column: repo_id
       references: repositories.id
@@ -1614,13 +1589,6 @@ catalogues:
       reason: enums.capability_exemption_reason
   service_capability_exemption:
     primary_key: id
-    description: 'A service''s declared, reasoned statement that it bears no product capability (M-ADR 0133 §4.2b). The services-tier equivalent of `repo_capability_exemption`, one tier down: `repo_capability_exemption` exists because M-ADR 0197 gave a repository a `services:` block, so a repository resolving under M-ADR 0188 no longer implies its services do. Emitted from the repo-config `service_capability_exemption:` block, keyed to the repo''s own default/primary service id — a declared, non-primary `services:` entry has no per-entry authoring surface yet (M-ADR 0197 §4.7, design-only) and cannot be exempted through this block.
-
-      Two reasons only (`enums.service_capability_exemption_reason`): `platform-internal` and `deprecated`. Narrower than the repository vocabulary by design — a service, by definition, already runs something, so the repository-tier packaging/tooling/provenance distinctions don''t reproduce here.
-
-      The invariant it participates in: every catalogued `services` row must resolve, either by carrying a `capability_service` edge or by declaring an exemption here — checked by a coverage predicate whose verdict set is tier-scoped (member tier cannot assert an unclaimed service is genuinely orphaned, only that it is unresolved locally; a cross-SDD claim on the service may exist in a sibling SDD''s own capability_service.csv, invisible to this SDD''s own build).
-
-      '
     columns:
     - name: id
       type: string
@@ -1635,6 +1603,10 @@ catalogues:
       type: string
       nullable: false
       description: Mandatory, non-empty. The reason code makes exemptions countable; the note makes them reviewable. A row with an empty note is dropped with a `convention` finding.
+    description: |
+      A service's declared, reasoned statement that it bears no product capability (M-ADR 0133 §4.2b). The services-tier equivalent of `repo_capability_exemption`, one tier down: `repo_capability_exemption` exists because M-ADR 0197 gave a repository a `services:` block, so a repository resolving under M-ADR 0188 no longer implies its services do. Emitted from the repo-config `service_capability_exemption:` block, keyed to the repo's own default/primary service id — a declared, non-primary `services:` entry has no per-entry authoring surface yet (M-ADR 0197 §4.7, design-only) and cannot be exempted through this block.
+      Two reasons only (`enums.service_capability_exemption_reason`): `platform-internal` and `deprecated`. Narrower than the repository vocabulary by design — a service, by definition, already runs something, so the repository-tier packaging/tooling/provenance distinctions don't reproduce here.
+      The invariant it participates in: every catalogued `services` row must resolve, either by carrying a `capability_service` edge or by declaring an exemption here — checked by a coverage predicate whose verdict set is tier-scoped (member tier cannot assert an unclaimed service is genuinely orphaned, only that it is unresolved locally; a cross-SDD claim on the service may exist in a sibling SDD's own capability_service.csv, invisible to this SDD's own build).
     foreign_keys:
     - column: service_id
       references: services.id
@@ -1643,11 +1615,6 @@ catalogues:
       reason: enums.service_capability_exemption_reason
   external_system_exemption:
     primary_key: id
-    description: 'A declared, reasoned assertion that an external-system candidate is GENUINELY external (M-ADR 0189 §4.6 / WS15). Annotation catalogue (M-ADR 0133 §4.2b): one FK, declared never derived, closed reason enum. Sourced from `orchestration/external-system-exemptions.yaml`.
-
-      The invariant it completes: c4_external_systems was the one catalogue family with no coverage predicate — a candidate producing no adjudication outcome was silent, and that silence hid a 28% dependency -graph distortion (ledger L4). Every candidate now either resolves at adjudication, or carries an exemption here, or is reported unverified. An exemption retires only the unverified finding — never an adjudication outcome (a converted candidate''s exemption is a contradiction, reported and dropped). Shared entities may be exempted by multiple SDDs: identical rows dedup at aggregation (same exception class as c4_external_systems); conflicting rows keep first-seen with a convention finding.
-
-      '
     columns:
     - name: id
       type: string
@@ -1663,6 +1630,9 @@ catalogues:
       type: string
       nullable: false
       description: Mandatory, non-empty. The reason makes exemptions countable; the note makes them reviewable (M-ADR 0188 §4.2 pattern).
+    description: |
+      A declared, reasoned assertion that an external-system candidate is GENUINELY external (M-ADR 0189 §4.6 / WS15). Annotation catalogue (M-ADR 0133 §4.2b): one FK, declared never derived, closed reason enum. Sourced from `orchestration/external-system-exemptions.yaml`.
+      The invariant it completes: c4_external_systems was the one catalogue family with no coverage predicate — a candidate producing no adjudication outcome was silent, and that silence hid a 28% dependency -graph distortion (ledger L4). Every candidate now either resolves at adjudication, or carries an exemption here, or is reported unverified. An exemption retires only the unverified finding — never an adjudication outcome (a converted candidate's exemption is a contradiction, reported and dropped). Shared entities may be exempted by multiple SDDs: identical rows dedup at aggregation (same exception class as c4_external_systems); conflicting rows keep first-seen with a convention finding.
     foreign_keys:
     - column: external_system_id
       references: c4_external_systems.id
@@ -1671,7 +1641,6 @@ catalogues:
       reason: enums.external_system_exemption_reason
   repo_contract:
     primary_key: id
-    description: 'Edge: repo is bound to a contract — implements or consumes; the source (contributes_to.artifact_type=contract-surface) does not distinguish, so this description asserts no direction (M-ADR 0211 §1). From contributes_to.artifact_type=contract-surface. Per M-ADR 0147 service-architecture external interfaces are a contract-consumes source; contract_id is external_for_profiles app/integration because their repos reference platform-resident (or platform-held BFF) contracts — resolved at aggregation, staying internal for platform-profile.'
     columns:
     - name: id
       type: string
@@ -1682,6 +1651,7 @@ catalogues:
     - name: contract_id
       type: string
       nullable: false
+    description: "Edge: repo is bound to a contract — implements or consumes; the source (contributes_to.artifact_type=contract-surface) does not distinguish, so this description asserts no direction (M-ADR 0211 §1). From contributes_to.artifact_type=contract-surface. Per M-ADR 0147 service-architecture external interfaces are a contract-consumes source; contract_id is external_for_profiles app/integration because their repos reference platform-resident (or platform-held BFF) contracts — resolved at aggregation, staying internal for platform-profile."
     foreign_keys:
     - column: repo_id
       references: repositories.id
@@ -1694,7 +1664,6 @@ catalogues:
       - integration-product
   product_capability:
     primary_key: id
-    description: 'Edge: product depends on / consumes capability. Forward sources from app-platform-dependencies.yaml. capability_id is external because the consuming product (an application-product SDD) references a capability owned by the platform SDD.'
     columns:
     - name: id
       type: string
@@ -1712,6 +1681,7 @@ catalogues:
     - name: notes
       type: string
       nullable: true
+    description: "Edge: product depends on / consumes capability. Forward sources from app-platform-dependencies.yaml. capability_id is external because the consuming product (an application-product SDD) references a capability owned by the platform SDD."
     foreign_keys:
     - column: product_id
       references: products.id
@@ -1724,7 +1694,6 @@ catalogues:
       role: enums.consumption_role
   product_service:
     primary_key: id
-    description: 'Edge: product depends on / consumes service. Forward sources from app-platform-dependencies.yaml. service_id is external because the consuming product (an application-product SDD) references a service owned by the platform SDD.'
     columns:
     - name: id
       type: string
@@ -1742,7 +1711,8 @@ catalogues:
     - name: required_stability
       type: string
       nullable: true
-      description: 'provisional | locked | unknown. The consuming SDD''s expectation of contract stability, carried verbatim from app-platform-dependencies.yaml. Not a bound enum: an out-of-vocabulary value is carried, not rejected, and is reported by validate-app-dependencies.sh.'
+      description: "provisional | locked | unknown. The consuming SDD's expectation of contract stability, carried verbatim from app-platform-dependencies.yaml. Not a bound enum: an out-of-vocabulary value is carried, not rejected, and is reported by validate-app-dependencies.sh."
+    description: "Edge: product depends on / consumes service. Forward sources from app-platform-dependencies.yaml. service_id is external because the consuming product (an application-product SDD) references a service owned by the platform SDD."
     foreign_keys:
     - column: product_id
       references: products.id
@@ -1755,12 +1725,11 @@ catalogues:
       role: enums.consumption_role
   service_contract:
     primary_key: id
-    description: 'Edge: service exposes or consumes contract. Both FKs are external (per M-ADR 0147): federated SDDs that walk per-repo service-architecture tables emit consumes rows where service_id resolves to the platform-root catalogue''s services.csv (post-aggregation) and contract_id resolves to the platform-root contracts.csv. Internal builds (e.g. connect-mono) still optimistically validate locally. Schema 2.8.0.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{service_id}__{contract_id}__{role}.'
+      description: "{service_id}__{contract_id}__{role}."
     - name: service_id
       type: string
       nullable: false
@@ -1771,6 +1740,7 @@ catalogues:
       type: string
       nullable: false
       description: exposes | consumes.
+    description: "Edge: service exposes or consumes contract. Both FKs are external (per M-ADR 0147): federated SDDs that walk per-repo service-architecture tables emit consumes rows where service_id resolves to the platform-root catalogue's services.csv (post-aggregation) and contract_id resolves to the platform-root contracts.csv. Internal builds (e.g. connect-mono) still optimistically validate locally. Schema 2.8.0."
     foreign_keys:
     - column: service_id
       references: services.id
@@ -1784,12 +1754,11 @@ catalogues:
       role: enums.contract_participation
   service_event:
     primary_key: id
-    description: 'Edge: service publishes or consumes event.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{service_id}__{event_id}__{role}.'
+      description: "{service_id}__{event_id}__{role}."
     - name: service_id
       type: string
       nullable: false
@@ -1800,6 +1769,7 @@ catalogues:
       type: string
       nullable: false
       description: publishes | consumes.
+    description: "Edge: service publishes or consumes event."
     foreign_keys:
     - column: service_id
       references: services.id
@@ -1811,12 +1781,11 @@ catalogues:
       role: enums.event_participation
   service_entity:
     primary_key: id
-    description: 'Edge: service touches data-model entity. Added in schema 2.13.0 per M-ADR 0159. Primary source: per-domain `## Data Store Mapping` markdown table in `docs/domains/{domain}/architecture/data-model.mermaid.md` (relation=owns). Optional forward source (Phase 5 deferred): `entities:` block in `orchestration/repo-config/<repo>.yaml`. Service names resolve via heuristic (slug-of-name; trailing-id-segment) with optional adopter-authored alias map at `docs/platform/reference/service-name-aliases.yaml`.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Composite PK: {service_id}__{entity_id}__{relation}.'
+      description: "Composite PK: {service_id}__{entity_id}__{relation}."
     - name: service_id
       type: string
       nullable: false
@@ -1826,7 +1795,7 @@ catalogues:
     - name: relation
       type: string
       nullable: false
-      description: 'Open string; recommended values: owns | reads | writes | references. Data Store Mapping table source emits `owns`. Values outside the recommended set fire `[finding] convention`.'
+      description: "Open string; recommended values: owns | reads | writes | references. Data Store Mapping table source emits `owns`. Values outside the recommended set fire `[finding] convention`."
     - name: evidence_path
       type: string
       nullable: true
@@ -1839,6 +1808,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Edge: service touches data-model entity. Added in schema 2.13.0 per M-ADR 0159. Primary source: per-domain `## Data Store Mapping` markdown table in `docs/domains/{domain}/architecture/data-model.mermaid.md` (relation=owns). Optional forward source (Phase 5 deferred): `entities:` block in `orchestration/repo-config/<repo>.yaml`. Service names resolve via heuristic (slug-of-name; trailing-id-segment) with optional adopter-authored alias map at `docs/platform/reference/service-name-aliases.yaml`."
     foreign_keys:
     - column: service_id
       references: services.id
@@ -1848,7 +1818,6 @@ catalogues:
       nullable: false
   capability_feature:
     primary_key: id
-    description: 'Edge: capability decomposes into features. Forward: traceability.runway.enables. Reverse: parsed from spec Feature Grounding.'
     columns:
     - name: id
       type: string
@@ -1859,6 +1828,7 @@ catalogues:
     - name: feature_id
       type: string
       nullable: false
+    description: "Edge: capability decomposes into features. Forward: traceability.runway.enables. Reverse: parsed from spec Feature Grounding."
     foreign_keys:
     - column: capability_id
       references: capabilities.id
@@ -1868,9 +1838,6 @@ catalogues:
       nullable: false
   capability_service:
     primary_key: id
-    description: 'Edge: capability is realised by services. Sourced from the capability traceability manifest services[] block. service_id is an external FK (schema 2.29.0, F4): a traceability entry marked `owner_sdd:` declares a cross-SDD reference (e.g. the service moved to a sibling SDD at an M-ADR 0170 §4.2 carve) — the per-SDD builder emits the edge, logs it `[finding] external`, and aggregation validates it hard against the owning sibling''s rows. An UNMARKED id that does not resolve locally is NOT emitted — it stays a member-tier orphan finding (or convention, when it names a known external system).
-
-      '
     columns:
     - name: id
       type: string
@@ -1884,11 +1851,11 @@ catalogues:
     - name: role
       type: string
       nullable: true
-      description: 'The part the service plays in delivering THIS capability — a property of the relationship, not of the service (capability-traceability-manifest-template). Closed enum, see enums.capability_service_role. Nullable: legacy rows may carry no role; the enum validator checks values, not presence. `dependency` rows are excluded from repo_capability Path X (M-ADR 0157 §4.3 as amended). Enum bound in 3.8.0.'
+      description: "The part the service plays in delivering THIS capability — a property of the relationship, not of the service (capability-traceability-manifest-template). Closed enum, see enums.capability_service_role. Nullable: legacy rows may carry no role; the enum validator checks values, not presence. `dependency` rows are excluded from repo_capability Path X (M-ADR 0157 §4.3 as amended). Enum bound in 3.8.0."
     - name: contract_id
       type: string
       nullable: true
-      description: 'The contract this dependency is against — a contracts.id declared as `contract:` on the services[] entry (M-ADR 0211 §4.1). External FK on the pattern of feature_contract: resolved at aggregation. Empty when the entry declares none; a `dependency`-role entry that reaches T4 band 5 carries it.'
+      description: "The contract this dependency is against — a contracts.id declared as `contract:` on the services[] entry (M-ADR 0211 §4.1). External FK on the pattern of feature_contract: resolved at aggregation. Empty when the entry declares none; a `dependency`-role entry that reaches T4 band 5 carries it."
     - name: interaction_pattern
       type: string
       nullable: true
@@ -1901,6 +1868,8 @@ catalogues:
       type: string
       nullable: true
       description: Where the coupling is evidenced — a path or anchor in the SDD, from `evidence:` on the services[] entry. Prose about the coupling stays in dependency_notes; this is the pointer a reviewer follows.
+    description: |
+      Edge: capability is realised by services. Sourced from the capability traceability manifest services[] block. service_id is an external FK (schema 2.29.0, F4): a traceability entry marked `owner_sdd:` declares a cross-SDD reference (e.g. the service moved to a sibling SDD at an M-ADR 0170 §4.2 carve) — the per-SDD builder emits the edge, logs it `[finding] external`, and aggregation validates it hard against the owning sibling's rows. An UNMARKED id that does not resolve locally is NOT emitted — it stays a member-tier orphan finding (or convention, when it names a known external system).
     foreign_keys:
     - column: capability_id
       references: capabilities.id
@@ -1918,7 +1887,6 @@ catalogues:
       interaction_pattern: enums.interaction_pattern
   capability_event:
     primary_key: id
-    description: 'Edge: capability publishes or consumes event. Schema 2.14.0 (per M-ADR 0160) multi-source ingestion: (1) forward shape A — `traceability.events[{id, role}]` (legacy aspirational shape, unauthored across observed adopters); (2) forward shape B — `traceability.contracts.published_events[]` / `consumed_events[]` with `{event, status, notes}` (the observed forward-method shape; event name slug-resolves against events.csv); (3) derived — `capability_service ⋈ service_event` join (zero authoring; associative not authoritative). Authored rows win on PK conflict with derived. The `source` column distinguishes the two so governance queries can filter to authoritative ownership. The earlier `## Related Events` capability-spec heading is retired (no adopter authored it; the template never carried the section).'
     columns:
     - name: id
       type: string
@@ -1937,6 +1905,7 @@ catalogues:
       type: string
       nullable: false
       description: authored | derived. `authored` rows come from a traceability declaration (shape A or shape B); `derived` rows come from `capability_service ⋈ service_event` and represent associative coupling, not ownership. Schema 2.14.0 per M-ADR 0160.
+    description: "Edge: capability publishes or consumes event. Schema 2.14.0 (per M-ADR 0160) multi-source ingestion: (1) forward shape A — `traceability.events[{id, role}]` (legacy aspirational shape, unauthored across observed adopters); (2) forward shape B — `traceability.contracts.published_events[]` / `consumed_events[]` with `{event, status, notes}` (the observed forward-method shape; event name slug-resolves against events.csv); (3) derived — `capability_service ⋈ service_event` join (zero authoring; associative not authoritative). Authored rows win on PK conflict with derived. The `source` column distinguishes the two so governance queries can filter to authoritative ownership. The earlier `## Related Events` capability-spec heading is retired (no adopter authored it; the template never carried the section)."
     foreign_keys:
     - column: capability_id
       references: capabilities.id
@@ -1948,7 +1917,6 @@ catalogues:
       role: enums.event_participation
   capability_contract:
     primary_key: id
-    description: 'Edge: capability is bound to a contract. Whether the capability exposes or depends on it is not stated by the source (traceability.contracts), so this description asserts no direction (M-ADR 0211 §1). Forward-declared only. Forward-declared only (traceability.contracts). The reverse derivation this description long claimed (service_contract ⋈ capability_service) was measured nonexistent — 0 `source: derived` rows across 105 units, builder references neither catalogue — and the CLAIM was corrected at 3.0.0 (M-ADR 0203 §4.5 / F2, gap class absent-derivation per M-ADR 0196 §4.1). The edge is forward-one-directional until a decision builds a reverse source.'
     columns:
     - name: id
       type: string
@@ -1962,7 +1930,8 @@ catalogues:
     - name: source
       type: string
       nullable: false
-      description: 'declared — the only emitted value. `derived` is reserved vocabulary: the reverse derivation it anticipated was never built (0 rows across 105 measured units) and the claim was corrected at 3.0.0 (M-ADR 0203 §4.5 / F2); the value re-enters if a decision builds a reverse source.'
+      description: "declared — the only emitted value. `derived` is reserved vocabulary: the reverse derivation it anticipated was never built (0 rows across 105 measured units) and the claim was corrected at 3.0.0 (M-ADR 0203 §4.5 / F2); the value re-enters if a decision builds a reverse source."
+    description: "Edge: capability is bound to a contract. Whether the capability exposes or depends on it is not stated by the source (traceability.contracts), so this description asserts no direction (M-ADR 0211 §1). Forward-declared only. Forward-declared only (traceability.contracts). The reverse derivation this description long claimed (service_contract ⋈ capability_service) was measured nonexistent — 0 `source: derived` rows across 105 units, builder references neither catalogue — and the CLAIM was corrected at 3.0.0 (M-ADR 0203 §4.5 / F2, gap class absent-derivation per M-ADR 0196 §4.1). The edge is forward-one-directional until a decision builds a reverse source."
     foreign_keys:
     - column: capability_id
       references: capabilities.id
@@ -1972,7 +1941,6 @@ catalogues:
       nullable: false
   journey_feature:
     primary_key: id
-    description: 'Edge: journey touches features. Parsed from Related features bullet.'
     columns:
     - name: id
       type: string
@@ -1983,6 +1951,7 @@ catalogues:
     - name: feature_id
       type: string
       nullable: false
+    description: "Edge: journey touches features. Parsed from Related features bullet."
     foreign_keys:
     - column: journey_id
       references: user_journeys.id
@@ -1992,7 +1961,6 @@ catalogues:
       nullable: false
   persona_feature:
     primary_key: id
-    description: 'Edge: persona uses features. Parsed from Related features bullet.'
     columns:
     - name: id
       type: string
@@ -2003,6 +1971,7 @@ catalogues:
     - name: feature_id
       type: string
       nullable: false
+    description: "Edge: persona uses features. Parsed from Related features bullet."
     foreign_keys:
     - column: persona_id
       references: personas.id
@@ -2012,7 +1981,6 @@ catalogues:
       nullable: false
   feature_service:
     primary_key: id
-    description: 'Edge: feature is implemented by service. Parsed from Feature Services table in feature-tree.md.'
     columns:
     - name: id
       type: string
@@ -2023,6 +1991,7 @@ catalogues:
     - name: service_id
       type: string
       nullable: false
+    description: "Edge: feature is implemented by service. Parsed from Feature Services table in feature-tree.md."
     foreign_keys:
     - column: feature_id
       references: features.id
@@ -2032,7 +2001,6 @@ catalogues:
       nullable: false
   feature_event:
     primary_key: id
-    description: 'Edge: feature publishes or consumes event. Derived only — emitted from the `feature_service ⋈ service_event` join, mirroring M-ADR 0160''s capability_event derived path one rung lower in the capability/feature/service hierarchy. Every row carries `source=derived`; there is no authored shape (the authored signal lives at the service level via `service_event`, which the feature inherits through `feature_service`). PK is `{feature_id}__{event_id}__{role}` so the same feature can carry both publishes + consumes rows for the same event without collision. Schema 2.15.0 per M-ADR 0161.'
     columns:
     - name: id
       type: string
@@ -2051,6 +2019,7 @@ catalogues:
       type: string
       nullable: false
       description: Always `derived` (schema 2.15.0). The column is retained for symmetry with `capability_event.source` and to keep the door open for an authored shape if one surfaces; today every row is derived.
+    description: "Edge: feature publishes or consumes event. Derived only — emitted from the `feature_service ⋈ service_event` join, mirroring M-ADR 0160's capability_event derived path one rung lower in the capability/feature/service hierarchy. Every row carries `source=derived`; there is no authored shape (the authored signal lives at the service level via `service_event`, which the feature inherits through `feature_service`). PK is `{feature_id}__{event_id}__{role}` so the same feature can carry both publishes + consumes rows for the same event without collision. Schema 2.15.0 per M-ADR 0161."
     foreign_keys:
     - column: feature_id
       references: features.id
@@ -2062,7 +2031,6 @@ catalogues:
       role: enums.event_participation
   feature_repo:
     primary_key: id
-    description: 'Edge: feature is implemented in repo. From contributes_to.artifact_type=feature-set.'
     columns:
     - name: id
       type: string
@@ -2073,6 +2041,7 @@ catalogues:
     - name: repo_id
       type: string
       nullable: false
+    description: "Edge: feature is implemented in repo. From contributes_to.artifact_type=feature-set."
     foreign_keys:
     - column: feature_id
       references: features.id
@@ -2082,12 +2051,11 @@ catalogues:
       nullable: false
   feature_contract:
     primary_key: id
-    description: 'Edge: feature is exposed via contract. Derived — forward: capability_feature ⋈ capability_contract (on capability_id); reverse: feature_service ⋈ service_contract (on service_id). Both join paths are run and merged; duplicate (feature_id, contract_id) pairs are deduplicated. contract_id is external for app/integration profiles where contracts live in the platform SDD. Added in schema 2.3.0.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{feature_id}__{contract_id}.'
+      description: "{feature_id}__{contract_id}."
     - name: feature_id
       type: string
       nullable: false
@@ -2098,6 +2066,7 @@ catalogues:
       type: string
       nullable: true
       description: cap-feature-cap-contract | feature-service-service-contract. Diagnostic only — records which join path produced the row.
+    description: "Edge: feature is exposed via contract. Derived — forward: capability_feature ⋈ capability_contract (on capability_id); reverse: feature_service ⋈ service_contract (on service_id). Both join paths are run and merged; duplicate (feature_id, contract_id) pairs are deduplicated. contract_id is external for app/integration profiles where contracts live in the platform SDD. Added in schema 2.3.0."
     foreign_keys:
     - column: feature_id
       references: features.id
@@ -2108,12 +2077,11 @@ catalogues:
       external: true
   feature_subscription_channels:
     primary_key: id
-    description: 'Edge: feature delivers async push via a named channel/topic. Peer of `graphql_operations:` in the per-feature evidence shape — `graphql_operations:` carries the GraphQL operation names declared in the schema (Queries / Mutations / Subscriptions); `feature_subscription_channels` rows carry the channel/topic layer that physically delivers the push events (AppSync WebSocket endpoints, Pekko WS channels, MQTT topics, server-sent-event streams). Per resolved decision §1 of `content/plans/v0-9-0-cohort-sweep-derived-bundle.md`: a single GraphQL Subscription operation may listen on multiple channels; one channel may be consumed by multiple operations — modelling as a separate edge catalogue (not as a feature column) accommodates the many-to-many. Built per-SDD from `reverse-evidence/feature-grounding-evidence.yaml` `subscription_channels:` entries on each feature. Added in schema 2.9.0.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{feature_id}__{channel_name}.'
+      description: "{feature_id}__{channel_name}."
     - name: feature_id
       type: string
       nullable: false
@@ -2124,7 +2092,7 @@ catalogues:
     - name: transport
       type: string
       nullable: false
-      description: 'Delivery protocol: `appsync-websocket | pekko-ws | mqtt | sse | webhook-push | other`. The `other` value is escape-valve; adopters using it SHOULD record the actual transport in evidence.'
+      description: "Delivery protocol: `appsync-websocket | pekko-ws | mqtt | sse | webhook-push | other`. The `other` value is escape-valve; adopters using it SHOULD record the actual transport in evidence."
     - name: evidence
       type: string
       nullable: true
@@ -2141,18 +2109,18 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Edge: feature delivers async push via a named channel/topic. Peer of `graphql_operations:` in the per-feature evidence shape — `graphql_operations:` carries the GraphQL operation names declared in the schema (Queries / Mutations / Subscriptions); `feature_subscription_channels` rows carry the channel/topic layer that physically delivers the push events (AppSync WebSocket endpoints, Pekko WS channels, MQTT topics, server-sent-event streams). Per resolved decision §1 of `content/plans/v0-9-0-cohort-sweep-derived-bundle.md`: a single GraphQL Subscription operation may listen on multiple channels; one channel may be consumed by multiple operations — modelling as a separate edge catalogue (not as a feature column) accommodates the many-to-many. Built per-SDD from `reverse-evidence/feature-grounding-evidence.yaml` `subscription_channels:` entries on each feature. Added in schema 2.9.0."
     foreign_keys:
     - column: feature_id
       references: features.id
       nullable: false
   capability_domain_model:
     primary_key: id
-    description: 'Edge: capability references a domain model. Forward: declared in `traceability.domain_model` field of the capability traceability manifest. Reverse: inferred via capability → domain → domain_model. Platform-profile only. Added in schema 2.4.0; see M-ADR 0142.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{capability_id}__{domain_model_id}.'
+      description: "{capability_id}__{domain_model_id}."
     - name: capability_id
       type: string
       nullable: false
@@ -2163,6 +2131,7 @@ catalogues:
       type: string
       nullable: false
       description: traceability-manifest | inferred.
+    description: "Edge: capability references a domain model. Forward: declared in `traceability.domain_model` field of the capability traceability manifest. Reverse: inferred via capability → domain → domain_model. Platform-profile only. Added in schema 2.4.0; see M-ADR 0142."
     foreign_keys:
     - column: capability_id
       references: capabilities.id
@@ -2172,12 +2141,11 @@ catalogues:
       nullable: false
   feature_domain_model:
     primary_key: id
-    description: 'Edge: feature operates on a domain model. Derived from capability_feature ⋈ capability_domain_model (on capability_id). Platform-profile only. Orphan features (no capability link) get no row. Added in schema 2.4.0; see M-ADR 0142.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{feature_id}__{domain_model_id}.'
+      description: "{feature_id}__{domain_model_id}."
     - name: feature_id
       type: string
       nullable: false
@@ -2188,6 +2156,7 @@ catalogues:
       type: string
       nullable: true
       description: cap-feature-cap-domain-model. Diagnostic only.
+    description: "Edge: feature operates on a domain model. Derived from capability_feature ⋈ capability_domain_model (on capability_id). Platform-profile only. Orphan features (no capability link) get no row. Added in schema 2.4.0; see M-ADR 0142."
     foreign_keys:
     - column: feature_id
       references: features.id
@@ -2197,7 +2166,6 @@ catalogues:
       nullable: false
   persona_journey:
     primary_key: id
-    description: 'Edge: persona participates in journey. Roles: primary | handoff | supporting.'
     columns:
     - name: id
       type: string
@@ -2212,6 +2180,7 @@ catalogues:
       type: string
       nullable: false
       description: primary | handoff | supporting.
+    description: "Edge: persona participates in journey. Roles: primary | handoff | supporting."
     foreign_keys:
     - column: persona_id
       references: personas.id
@@ -2223,12 +2192,11 @@ catalogues:
       role: enums.journey_participation
   persona_c4system:
     primary_key: id
-    description: 'Edge: persona (C4 Person) uses a C4 system. Captures the L1 context ''Person uses System'' relationship, extracted from Person(...) macros on the L1 context diagram and matched to personas rows. Per M-ADR 0155. Added in schema 2.10.0.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{persona_id}__{c4_system_id}.'
+      description: "{persona_id}__{c4_system_id}."
     - name: persona_id
       type: string
       nullable: false
@@ -2239,6 +2207,7 @@ catalogues:
       type: string
       nullable: true
       description: Optional interaction label from the Rel(...) line, e.g. 'Web browser' / 'Mobile app'.
+    description: "Edge: persona (C4 Person) uses a C4 system. Captures the L1 context 'Person uses System' relationship, extracted from Person(...) macros on the L1 context diagram and matched to personas rows. Per M-ADR 0155. Added in schema 2.10.0."
     foreign_keys:
     - column: persona_id
       references: personas.id
@@ -2248,14 +2217,11 @@ catalogues:
       nullable: false
   persona_container:
     primary_key: id
-    description: 'Edge: a persona uses a C4 container — the L2-granularity companion to persona_c4system (M-ADR 0189 F26 §3, ratified 2026-07-10). Eleven of one estate''s L2 diagrams and the bulk of another''s 81 unroutable Rels drew Person→Container relationships that had no catalogue and, until F26, no finding. Harvested at member tier from Rel(...) lines whose endpoints resolve to a file-local Person and a local container (either direction; the row is normalised persona→container). A Person that matches no persona row is a coverage finding, never a silent skip. Both authoring directions feed from the same diagram surface (M-ADR 0157 parity). Added in schema 2.34.0.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{persona_id}__{container_id}.'
+      description: "{persona_id}__{container_id}."
     - name: persona_id
       type: string
       nullable: false
@@ -2266,6 +2232,8 @@ catalogues:
       type: string
       nullable: true
       description: Optional interaction label from the Rel(...) line. May hold multiple '; '-joined labels (F25).
+    description: |
+      Edge: a persona uses a C4 container — the L2-granularity companion to persona_c4system (M-ADR 0189 F26 §3, ratified 2026-07-10). Eleven of one estate's L2 diagrams and the bulk of another's 81 unroutable Rels drew Person→Container relationships that had no catalogue and, until F26, no finding. Harvested at member tier from Rel(...) lines whose endpoints resolve to a file-local Person and a local container (either direction; the row is normalised persona→container). A Person that matches no persona row is a coverage finding, never a silent skip. Both authoring directions feed from the same diagram surface (M-ADR 0157 parity). Added in schema 2.34.0.
     foreign_keys:
     - column: persona_id
       references: personas.id
@@ -2275,12 +2243,11 @@ catalogues:
       nullable: false
   system_external_dependency:
     primary_key: id
-    description: 'Edge: a C4 system integrates with an external software system. Captures the L1 context ''System integrates with External System'' relationship, extracted from System_Ext(...) + Rel(...) on L1/L2 diagrams. Per M-ADR 0155. Container-level external dependencies are out of scope (system-level only). Added in schema 2.10.0. From 2.30.0 (M-ADR 0189 §4.4): edges whose external endpoint the aggregator adjudicates as an INTERNAL system are rewritten onto system_system_dependency and removed from this catalogue.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{c4_system_id}__{external_system_id}.'
+      description: "{c4_system_id}__{external_system_id}."
     - name: c4_system_id
       type: string
       nullable: false
@@ -2295,6 +2262,7 @@ catalogues:
       type: string
       nullable: true
       description: The Rel's non-external endpoint resolved to a local container at member tier, when it is one (F17, 2.33.0) — the datum that lets adjudication rewrite this edge onto container_dependency instead of destroying it. Empty when the endpoint is the system itself or unresolvable.
+    description: "Edge: a C4 system integrates with an external software system. Captures the L1 context 'System integrates with External System' relationship, extracted from System_Ext(...) + Rel(...) on L1/L2 diagrams. Per M-ADR 0155. Container-level external dependencies are out of scope (system-level only). Added in schema 2.10.0. From 2.30.0 (M-ADR 0189 §4.4): edges whose external endpoint the aggregator adjudicates as an INTERNAL system are rewritten onto system_system_dependency and removed from this catalogue."
     foreign_keys:
     - column: c4_system_id
       references: c4_systems.id
@@ -2307,14 +2275,11 @@ catalogues:
       nullable: true
   container_dependency:
     primary_key: id
-    description: 'Edge: a C4 container depends on another INTERNAL container (adopter finding F17 — F6 exactly one tier down: "no edge for internal" at L2). Derived by the aggregator at adjudication: an external-system candidate that resolves to an internal container was never external — each of its dependency edges whose member-resolved `from_container_id` is known is rewritten here, and a candidate with no remaining edges is dropped (it was a phantom duplicate of the container). A candidate with unconvertible edges is kept with the tier-contradiction finding, so no edge is ever destroyed to make a build quieter — the measured cost that stopped an adopter remediating 22 contradictions was eight real edges. ALSO emitted at member tier (F19, 2.33.1): the C4-correct authoring — Rel(container_a, container_b) between two Container(...) nodes — emits its edge directly; adjudication merges into a catalogue that already has content rather than being its only source, so the metamodel no longer rewards mis-declaration over correct authoring. Added in schema 2.33.0.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{from_container_id}__{to_container_id}.'
+      description: "{from_container_id}__{to_container_id}."
     - name: from_container_id
       type: string
       nullable: false
@@ -2333,6 +2298,8 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Edge: a C4 container depends on another INTERNAL container (adopter finding F17 — F6 exactly one tier down: "no edge for internal" at L2). Derived by the aggregator at adjudication: an external-system candidate that resolves to an internal container was never external — each of its dependency edges whose member-resolved `from_container_id` is known is rewritten here, and a candidate with no remaining edges is dropped (it was a phantom duplicate of the container). A candidate with unconvertible edges is kept with the tier-contradiction finding, so no edge is ever destroyed to make a build quieter — the measured cost that stopped an adopter remediating 22 contradictions was eight real edges. ALSO emitted at member tier (F19, 2.33.1): the C4-correct authoring — Rel(container_a, container_b) between two Container(...) nodes — emits its edge directly; adjudication merges into a catalogue that already has content rather than being its only source, so the metamodel no longer rewards mis-declaration over correct authoring. Added in schema 2.33.0.
     foreign_keys:
     - column: from_container_id
       references: c4_containers.id
@@ -2342,14 +2309,11 @@ catalogues:
       nullable: false
   system_system_dependency:
     primary_key: id
-    description: 'Edge: a C4 system depends on another INTERNAL system (M-ADR 0189 §4.3). Derived by the aggregator at adjudication (§4.4): an external-system candidate whose declared identity resolves to an internal system was never external — its Rel(...) dependency edges are rewritten onto this catalogue and the candidate row is dropped. Not emitted at member tier (a member cannot see sibling systems); headers-only there, like cross_sdd_platform_capability. Both authoring directions feed it from the same diagram surface (M-ADR 0157 parity). Added in schema 2.30.0.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{from_system_id}__{to_system_id}.'
+      description: "{from_system_id}__{to_system_id}."
     - name: from_system_id
       type: string
       nullable: false
@@ -2368,6 +2332,8 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Edge: a C4 system depends on another INTERNAL system (M-ADR 0189 §4.3). Derived by the aggregator at adjudication (§4.4): an external-system candidate whose declared identity resolves to an internal system was never external — its Rel(...) dependency edges are rewritten onto this catalogue and the candidate row is dropped. Not emitted at member tier (a member cannot see sibling systems); headers-only there, like cross_sdd_platform_capability. Both authoring directions feed it from the same diagram surface (M-ADR 0157 parity). Added in schema 2.30.0.
     foreign_keys:
     - column: from_system_id
       references: c4_systems.id
@@ -2377,12 +2343,11 @@ catalogues:
       nullable: false
   c4_container_entity:
     primary_key: id
-    description: 'Derived edge: C4 container is responsible for data-model entity. Added in schema 2.13.0 per M-ADR 0159 §4.8. Pure transitive derivation: `service_entity ⋈ c4_containers.service_id`. Only the subset of containers with `service_id` populated contribute edges (per M-ADR 0155 the container ↔ service cardinality is o-or-1; data-store containers and infra-umbrella containers without a service mapping legitimately emit no rows).'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Composite PK: {container_id}__{entity_id}.'
+      description: "Composite PK: {container_id}__{entity_id}."
     - name: container_id
       type: string
       nullable: false
@@ -2400,6 +2365,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Derived edge: C4 container is responsible for data-model entity. Added in schema 2.13.0 per M-ADR 0159 §4.8. Pure transitive derivation: `service_entity ⋈ c4_containers.service_id`. Only the subset of containers with `service_id` populated contribute edges (per M-ADR 0155 the container ↔ service cardinality is o-or-1; data-store containers and infra-umbrella containers without a service mapping legitimately emit no rows)."
     foreign_keys:
     - column: container_id
       references: c4_containers.id
@@ -2409,12 +2375,11 @@ catalogues:
       nullable: false
   c4_system_entity:
     primary_key: id
-    description: 'Derived edge: C4 system is responsible for data-model entity. Added in schema 2.13.0 per M-ADR 0159 §4.8. Pure aggregation roll-up: `c4_container_entity ⋈ c4_containers.system_id`, with container_count recording how many of the system''s containers touch the entity (governance signal for cross-container concerns).'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Composite PK: {system_id}__{entity_id}.'
+      description: "Composite PK: {system_id}__{entity_id}."
     - name: system_id
       type: string
       nullable: false
@@ -2432,6 +2397,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Derived edge: C4 system is responsible for data-model entity. Added in schema 2.13.0 per M-ADR 0159 §4.8. Pure aggregation roll-up: `c4_container_entity ⋈ c4_containers.system_id`, with container_count recording how many of the system's containers touch the entity (governance signal for cross-container concerns)."
     foreign_keys:
     - column: system_id
       references: c4_systems.id
@@ -2441,7 +2407,6 @@ catalogues:
       nullable: false
   capability_adr:
     primary_key: id
-    description: 'Edge: ADR informs capability. Forward: declared in capability spec Architecture Decisions. Reverse: same plus heuristic match supplements with confidence.'
     columns:
     - name: id
       type: string
@@ -2456,6 +2421,7 @@ catalogues:
       type: string
       nullable: false
       description: spec | high | medium.
+    description: "Edge: ADR informs capability. Forward: declared in capability spec Architecture Decisions. Reverse: same plus heuristic match supplements with confidence."
     foreign_keys:
     - column: capability_id
       references: capabilities.id
@@ -2465,7 +2431,6 @@ catalogues:
       nullable: false
   adr_supersedes:
     primary_key: id
-    description: 'Edge: superseding ADR → superseded ADR. Parsed from Supersedes bullets where prose references a known ADR id.'
     columns:
     - name: id
       type: string
@@ -2476,6 +2441,7 @@ catalogues:
     - name: superseded_adr_id
       type: string
       nullable: false
+    description: "Edge: superseding ADR → superseded ADR. Parsed from Supersedes bullets where prose references a known ADR id."
     foreign_keys:
     - column: superseding_adr_id
       references: adrs.id
@@ -2485,14 +2451,11 @@ catalogues:
       nullable: false
   product_platform_dependencies:
     primary_key: id
-    description: 'Per-SDD edge: an application-side or integration-side SDD declares that its product depends on a platform-side capability + service pair. Built from `reverse-evidence/feature-grounding-evidence.yaml` `platform_dependencies:` block (product-level — the cohort source shape carries product-scoped dependency rows with a `consumed_by:` list naming which services within the consuming product depend on the target). Each row records one (consuming product, target capability, target service) triple. The aggregator then joins these rows against platform-side `capability_service` to emit `cross_sdd_platform_capability` edges at aggregation time. Cross- SDD references (target_capability_id, target_service_id) are external — they''re not expected to resolve in the per-SDD build, only at aggregation. Added in schema 2.9.0; see `content/plans/v0-9-0-cohort-sweep-derived-bundle.md` §"Cross-SDD platform-capability-edge".
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{product_id}__{target_capability_id}__{target_service_id}, EXCEPT for async shared-stream rows (M-ADR 0192) where there is no realiser service: the third component falls back to the stream contract_path, i.e. {product_id}__{target_capability_id}__{contract_path}. For OFF-PLATFORM rows (M-ADR 0204, target_locus external|legacy) there is no platform capability either: id = {product_id}__{target_locus}__{target_external_system_id}, falling back to contract_path as the third component when no external-system id is named. This keeps the PK stable and collision-free when a product depends on the same capability via two distinct streams.'
+      description: "{product_id}__{target_capability_id}__{target_service_id}, EXCEPT for async shared-stream rows (M-ADR 0192) where there is no realiser service: the third component falls back to the stream contract_path, i.e. {product_id}__{target_capability_id}__{contract_path}. For OFF-PLATFORM rows (M-ADR 0204, target_locus external|legacy) there is no platform capability either: id = {product_id}__{target_locus}__{target_external_system_id}, falling back to contract_path as the third component when no external-system id is named. This keeps the PK stable and collision-free when a product depends on the same capability via two distinct streams."
     - name: product_id
       type: string
       nullable: false
@@ -2500,7 +2463,7 @@ catalogues:
     - name: target_capability_id
       type: string
       nullable: true
-      description: 'Capability the consuming product depends on. Resolves at aggregation against a sibling SDD''s capabilities.id; external by definition. Conditionally nullable (M-ADR 0204 §4.3): EMPTY when target_locus is external|legacy — there is no platform capability to name on an off-platform row, and demanding a value is what put a product''s own feature slug in this column. A platform-locus row still requires it.'
+      description: "Capability the consuming product depends on. Resolves at aggregation against a sibling SDD's capabilities.id; external by definition. Conditionally nullable (M-ADR 0204 §4.3): EMPTY when target_locus is external|legacy — there is no platform capability to name on an off-platform row, and demanding a value is what put a product's own feature slug in this column. A platform-locus row still requires it."
     - name: target_locus
       type: string
       nullable: true
@@ -2508,11 +2471,11 @@ catalogues:
     - name: target_external_system_id
       type: string
       nullable: true
-      description: 'For target_locus external|legacy rows only: the M-ADR 0189 external-system entry id the dependency targets (authored in the source file''s service_id slot; the builder routes it here so the FK columns stay clean). Deliberately NOT a declared FK: corroboration against c4_external_systems is WARNING-severity at aggregation (M-ADR 0204 §4.2), because the C4 surface may legitimately lag discovery, and a declared FK can only fail.'
+      description: "For target_locus external|legacy rows only: the M-ADR 0189 external-system entry id the dependency targets (authored in the source file's service_id slot; the builder routes it here so the FK columns stay clean). Deliberately NOT a declared FK: corroboration against c4_external_systems is WARNING-severity at aggregation (M-ADR 0204 §4.2), because the C4 surface may legitimately lag discovery, and a declared FK can only fail."
     - name: target_service_id
       type: string
       nullable: true
-      description: 'Service identifier the consuming product depends on. Resolves at aggregation against a sibling SDD''s services.id; external by definition. The join key the aggregator uses to derive cross_sdd_platform_capability for SYNCHRONOUS dependencies. Conditionally nullable (M-ADR 0192): for an async shared-stream dependency (contract_type in the async set — `event`/`event-stream`/`stream`) there is no single realiser service, so this is empty and the dependency binds to the stream contract_path + target_capability_id instead. A synchronous contract_type still requires it. Made nullable in schema 2.36.0.'
+      description: "Service identifier the consuming product depends on. Resolves at aggregation against a sibling SDD's services.id; external by definition. The join key the aggregator uses to derive cross_sdd_platform_capability for SYNCHRONOUS dependencies. Conditionally nullable (M-ADR 0192): for an async shared-stream dependency (contract_type in the async set — `event`/`event-stream`/`stream`) there is no single realiser service, so this is empty and the dependency binds to the stream contract_path + target_capability_id instead. A synchronous contract_type still requires it. Made nullable in schema 2.36.0."
     - name: target_domain
       type: string
       nullable: true
@@ -2524,7 +2487,7 @@ catalogues:
     - name: required_stability
       type: string
       nullable: true
-      description: 'provisional | locked | unknown. Optional; the consuming SDD''s expectation of contract stability — and only that: where the target lives and what lifecycle its implementation is in are separate concerns that do not belong in this field. Not a bound enum: an out-of-vocabulary value is carried, not rejected, and is reported by validate-app-dependencies.sh.'
+      description: "provisional | locked | unknown. Optional; the consuming SDD's expectation of contract stability — and only that: where the target lives and what lifecycle its implementation is in are separate concerns that do not belong in this field. Not a bound enum: an out-of-vocabulary value is carried, not rejected, and is reported by validate-app-dependencies.sh."
     - name: contract_path
       type: string
       nullable: true
@@ -2541,6 +2504,8 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Per-SDD edge: an application-side or integration-side SDD declares that its product depends on a platform-side capability + service pair. Built from `reverse-evidence/feature-grounding-evidence.yaml` `platform_dependencies:` block (product-level — the cohort source shape carries product-scoped dependency rows with a `consumed_by:` list naming which services within the consuming product depend on the target). Each row records one (consuming product, target capability, target service) triple. The aggregator then joins these rows against platform-side `capability_service` to emit `cross_sdd_platform_capability` edges at aggregation time. Cross- SDD references (target_capability_id, target_service_id) are external — they're not expected to resolve in the per-SDD build, only at aggregation. Added in schema 2.9.0; see `content/plans/v0-9-0-cohort-sweep-derived-bundle.md` §"Cross-SDD platform-capability-edge".
     foreign_keys:
     - column: product_id
       references: products.id
@@ -2555,14 +2520,11 @@ catalogues:
       external: true
   cross_sdd_platform_capability:
     primary_key: id
-    description: 'Federated edge: an application-side or integration-side SDD''s `product_platform_dependencies` reference resolves against a platform-side SDD''s capability spec via the platform capability''s `capability_service` roster. Surfaces ecosystem-wide platform- consumer relationships at product → capability granularity. Built **only at aggregation time** — `sdd-cli catalogue aggregate` joins each consuming SDD''s `product_platform_dependencies` rows against every other SDD''s `capability_service` rows on `target_service_id == service_id`, emitting one row per resolved (consuming-product, platform-capability) pair. Per-SDD builders emit nothing for this catalogue; the aggregator owns it entirely. A platform-dependency whose target_service_id doesn''t resolve to any platform-side capability_service row is logged as an `orphan` finding and produces no row. Cross-SDD references are external by definition. Added in schema 2.9.0; see `content/plans/v0-9-0-cohort-sweep-derived-bundle.md` §"Cross-SDD platform-capability-edge" and M-ADR 0134.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{consuming_sdd_id}__{consuming_product_id}__{platform_sdd_id}__{platform_capability_id}__{service_id}. Composite encoding so the same (consuming product, platform capability) pair can appear once per resolving service when a product depends on multiple services owned by the same capability.'
+      description: "{consuming_sdd_id}__{consuming_product_id}__{platform_sdd_id}__{platform_capability_id}__{service_id}. Composite encoding so the same (consuming product, platform capability) pair can appear once per resolving service when a product depends on multiple services owned by the same capability."
     - name: consuming_sdd_id
       type: string
       nullable: false
@@ -2583,6 +2545,8 @@ catalogues:
       type: string
       nullable: false
       description: Service identifier the consuming SDD references and the platform SDD owns. The join key.
+    description: |
+      Federated edge: an application-side or integration-side SDD's `product_platform_dependencies` reference resolves against a platform-side SDD's capability spec via the platform capability's `capability_service` roster. Surfaces ecosystem-wide platform- consumer relationships at product → capability granularity. Built **only at aggregation time** — `sdd-cli catalogue aggregate` joins each consuming SDD's `product_platform_dependencies` rows against every other SDD's `capability_service` rows on `target_service_id == service_id`, emitting one row per resolved (consuming-product, platform-capability) pair. Per-SDD builders emit nothing for this catalogue; the aggregator owns it entirely. A platform-dependency whose target_service_id doesn't resolve to any platform-side capability_service row is logged as an `orphan` finding and produces no row. Cross-SDD references are external by definition. Added in schema 2.9.0; see `content/plans/v0-9-0-cohort-sweep-derived-bundle.md` §"Cross-SDD platform-capability-edge" and M-ADR 0134.
     foreign_keys:
     - column: consuming_product_id
       references: products.id
@@ -2598,14 +2562,11 @@ catalogues:
       external: true
   application_data_plane_bindings:
     primary_key: id
-    description: 'Application-product edge (M-ADR 0193): one row per declared data-plane binding — a typed way the service sources, holds, produces or exposes data. The data-plane is a COMPOSITION of these bindings, a second axis orthogonal to `application_archetype` (0191). Built per-SDD from the manifest''s `data_plane.bindings` block (application-product only; other profiles emit headers-only). The `pattern` vocabulary splits by DIRECTION (§4.7): an INBOUND data-sourcing sub-set (retrieve | own-store | stream-ingest | project) and an OUTPUT-side sub-set (generate | publish), materialised as the derived `direction` column. An INBOUND binding whose `target` is a platform capability/service reconciles with `product_platform_dependencies` — a `retrieve@internal` binding is a synchronous platform dependency and a `stream-ingest@internal` binding is the M-ADR 0192 `contract_type: event` async dependency; the genuinely new inbound rows are `own-store` (a self-binding) and any `external-vendor` binding. OUTPUT-side rows do NOT participate in that reconciliation (§4.7 rule 1): `publish` is a contract the service PROVIDES, not one it consumes, so it has no inbound counterpart to cross-check — consumers must filter on `direction` before reconciling, which is what the column is for. The archetype-default-vs-declared WARN keys on the bare `pattern` token and so spans both directions (§4.7 rule 2). Added in schema 2.37.0; `direction` added in 2.40.0.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{product_id}__{pattern}__{locality}__{target} (empty components collapse to blanks). A duplicate emits a divergence finding and is dropped. `direction` is NOT a component — it is derived from `pattern`, so it adds nothing to identity.'
+      description: "{product_id}__{pattern}__{locality}__{target} (empty components collapse to blanks). A duplicate emits a divergence finding and is dropped. `direction` is NOT a component — it is derived from `pattern`, so it adds nothing to identity."
     - name: product_id
       type: string
       nullable: false
@@ -2613,15 +2574,15 @@ catalogues:
     - name: pattern
       type: string
       nullable: false
-      description: 'Closed method-tier enum: retrieve | own-store | stream-ingest | project (inbound, data-sourcing) | generate | publish (output-side, per M-ADR 0193 §4.7). How the data relates to the service (§4.1).'
+      description: "Closed method-tier enum: retrieve | own-store | stream-ingest | project (inbound, data-sourcing) | generate | publish (output-side, per M-ADR 0193 §4.7). How the data relates to the service (§4.1)."
     - name: direction
       type: string
       nullable: false
-      description: 'inbound | output. DERIVED from `pattern` by a single method-tier mapping — not authored, and not a manifest field, so it cannot disagree with `pattern`. Materialises the output-side sub-set §4.7 declares (generate/publish => output; everything else => inbound). Exists because three §4.7 rules branch on direction: platform-dep reconciliation is inbound-only, the archetype WARN must compare like with like, and the M-ADR 0187 convergence reasoning differs by direction. Added in 2.40.0.'
+      description: "inbound | output. DERIVED from `pattern` by a single method-tier mapping — not authored, and not a manifest field, so it cannot disagree with `pattern`. Materialises the output-side sub-set §4.7 declares (generate/publish => output; everything else => inbound). Exists because three §4.7 rules branch on direction: platform-dep reconciliation is inbound-only, the archetype WARN must compare like with like, and the M-ADR 0187 convergence reasoning differs by direction. Added in 2.40.0."
     - name: locality
       type: string
       nullable: true
-      description: 'Closed enum: internal-platform | internal-domain | external-vendor. Where the other end sits. REQUIRED on the inbound data-sourcing patterns (retrieve/stream-ingest/project); may be empty for own-store (a self-binding with no other end) and for the output-side patterns (generate/publish), which may carry one but do not require it (M-ADR 0193 §4.7).'
+      description: "Closed enum: internal-platform | internal-domain | external-vendor. Where the other end sits. REQUIRED on the inbound data-sourcing patterns (retrieve/stream-ingest/project); may be empty for own-store (a self-binding with no other end) and for the output-side patterns (generate/publish), which may carry one but do not require it (M-ADR 0193 §4.7)."
     - name: transport
       type: string
       nullable: true
@@ -2646,20 +2607,19 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Application-product edge (M-ADR 0193): one row per declared data-plane binding — a typed way the service sources, holds, produces or exposes data. The data-plane is a COMPOSITION of these bindings, a second axis orthogonal to `application_archetype` (0191). Built per-SDD from the manifest's `data_plane.bindings` block (application-product only; other profiles emit headers-only). The `pattern` vocabulary splits by DIRECTION (§4.7): an INBOUND data-sourcing sub-set (retrieve | own-store | stream-ingest | project) and an OUTPUT-side sub-set (generate | publish), materialised as the derived `direction` column. An INBOUND binding whose `target` is a platform capability/service reconciles with `product_platform_dependencies` — a `retrieve@internal` binding is a synchronous platform dependency and a `stream-ingest@internal` binding is the M-ADR 0192 `contract_type: event` async dependency; the genuinely new inbound rows are `own-store` (a self-binding) and any `external-vendor` binding. OUTPUT-side rows do NOT participate in that reconciliation (§4.7 rule 1): `publish` is a contract the service PROVIDES, not one it consumes, so it has no inbound counterpart to cross-check — consumers must filter on `direction` before reconciling, which is what the column is for. The archetype-default-vs-declared WARN keys on the bare `pattern` token and so spans both directions (§4.7 rule 2). Added in schema 2.37.0; `direction` added in 2.40.0.
     foreign_keys:
     - column: product_id
       references: products.id
       nullable: false
   application_data_plane_deviations:
     primary_key: id
-    description: 'Application-product annotation (M-ADR 0191 §4.3 overlay): one row per declared departure from the archetype''s default data-plane composition. Built per-SDD from the manifest''s `data_plane.deviations` block so the overlay WARN — which runs at AGGREGATION tier, where the reference- architecture bundle (and its `expected_bindings`) resolves — can suppress a mismatch it is told is sanctioned variance. The `expectation` value is the **bare pattern token** (`retrieve` | `own-store` | `stream-ingest` | `project` | `generate` | `publish`) that the product knowingly diverges from; it must match the pattern the WARN keys on. The token set spans both directions — the WARN keys on the bare pattern, so an output-side expectation is deviated exactly like an inbound one (M-ADR 0193 §4.7 rule 2). Added in schema 2.38.0; output-side tokens documented in 2.40.0.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{product_id}__{expectation}. A duplicate emits a divergence finding and is dropped.'
+      description: "{product_id}__{expectation}. A duplicate emits a divergence finding and is dropped."
     - name: product_id
       type: string
       nullable: false
@@ -2680,20 +2640,19 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Application-product annotation (M-ADR 0191 §4.3 overlay): one row per declared departure from the archetype's default data-plane composition. Built per-SDD from the manifest's `data_plane.deviations` block so the overlay WARN — which runs at AGGREGATION tier, where the reference- architecture bundle (and its `expected_bindings`) resolves — can suppress a mismatch it is told is sanctioned variance. The `expectation` value is the **bare pattern token** (`retrieve` | `own-store` | `stream-ingest` | `project` | `generate` | `publish`) that the product knowingly diverges from; it must match the pattern the WARN keys on. The token set spans both directions — the WARN keys on the bare pattern, so an output-side expectation is deviated exactly like an inbound one (M-ADR 0193 §4.7 rule 2). Added in schema 2.38.0; output-side tokens documented in 2.40.0.
     foreign_keys:
     - column: product_id
       references: products.id
       nullable: false
   application_conformance_coverage:
     primary_key: id
-    description: 'Application-product annotation (M-ADR 0191 §4.3 overlay, second element — WS4): one row per conformance tag the product asserts about its archetype''s conformance expectations. Built per-SDD from the manifest''s `conformance` block so the AGGREGATION-tier conformance GATE can read it. `status=covered` means the product''s own conformance suite exercises the tag; `status=deviated` means the product declares (with a rationale) that it deliberately does not. At aggregation, an archetype-expected conformance tag that is neither covered nor deviated raises a deviation-visible WARN. The method gates the DECLARATION — it does not run the adopter''s conformance suite. Added in schema 2.39.0.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: '{product_id}__{tag}. A duplicate emits a divergence finding and is dropped.'
+      description: "{product_id}__{tag}. A duplicate emits a divergence finding and is dropped."
     - name: product_id
       type: string
       nullable: false
@@ -2718,18 +2677,19 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Application-product annotation (M-ADR 0191 §4.3 overlay, second element — WS4): one row per conformance tag the product asserts about its archetype's conformance expectations. Built per-SDD from the manifest's `conformance` block so the AGGREGATION-tier conformance GATE can read it. `status=covered` means the product's own conformance suite exercises the tag; `status=deviated` means the product declares (with a rationale) that it deliberately does not. At aggregation, an archetype-expected conformance tag that is neither covered nor deviated raises a deviation-visible WARN. The method gates the DECLARATION — it does not run the adopter's conformance suite. Added in schema 2.39.0.
     foreign_keys:
     - column: product_id
       references: products.id
       nullable: false
   screens:
     primary_key: id
-    description: 'UI screen specified in the OpenUI Lang grammar (per M-ADR 0166). One row per screen / coherent screen group. Application-product profile (other profiles emit headers-only). Source: authored `screens/*.md` (frontmatter + ```openui-lang block); the reverse toolkit produces these from a router + component-tree projection.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Slugged PK: {product_id}-{screen-slug}.'
+      description: "Slugged PK: {product_id}-{screen-slug}."
     - name: name
       type: string
       nullable: false
@@ -2765,7 +2725,7 @@ catalogues:
     - name: evidence_class
       type: string
       nullable: true
-      description: 'Evidence class of the screen''s claims, from frontmatter `evidence_class:` (alias `evidence-class:`). Free-form; conventional values code-reverse | vendor-doc | operational (M-ADR 0175). Empty when undeclared. Completes the evidence-class dimension for the packaged-SaaS case: a packaged-SaaS SDD catalogues the vendor''s STANDARD screens (documentation-reversed from vendor publications, `vendor-doc`) alongside the organisation''s CUSTOMISED screens (code-reversed, `code-reverse`) per M-ADR 0175 §3.1 — without this column the two are indistinguishable, and doc-derived UI claims masquerade as code-verified. Orthogonal to `source` (`screen-spec` | `screen-extraction`), which records the authoring DIRECTION, not the evidence''s strength: a `screen-extraction` screen can be either class, since a vendor''s documented UI is extracted-but-not-code-verified. Added in schema 2.42.0.'
+      description: "Evidence class of the screen's claims, from frontmatter `evidence_class:` (alias `evidence-class:`). Free-form; conventional values code-reverse | vendor-doc | operational (M-ADR 0175). Empty when undeclared. Completes the evidence-class dimension for the packaged-SaaS case: a packaged-SaaS SDD catalogues the vendor's STANDARD screens (documentation-reversed from vendor publications, `vendor-doc`) alongside the organisation's CUSTOMISED screens (code-reversed, `code-reverse`) per M-ADR 0175 §3.1 — without this column the two are indistinguishable, and doc-derived UI claims masquerade as code-verified. Orthogonal to `source` (`screen-spec` | `screen-extraction`), which records the authoring DIRECTION, not the evidence's strength: a `screen-extraction` screen can be either class, since a vendor's documented UI is extracted-but-not-code-verified. Added in schema 2.42.0."
     - name: source_sdd_id
       type: string
       nullable: true
@@ -2774,18 +2734,18 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "UI screen specified in the OpenUI Lang grammar (per M-ADR 0166). One row per screen / coherent screen group. Application-product profile (other profiles emit headers-only). Source: authored `screens/*.md` (frontmatter + ```openui-lang block); the reverse toolkit produces these from a router + component-tree projection."
     foreign_keys:
     - column: product_id
       references: products.id
       nullable: false
   ui_components:
     primary_key: id
-    description: 'An entry in the adopter-owned component registry that screens compose against (per M-ADR 0166) — the UI-structure contract. A screen composes registry components but never defines one. Application-product profile. Source: components referenced across the SDD''s screen-spec ```openui-lang blocks (registry projection); the reverse toolkit discovers the authoritative registry from the design-system import surface.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Slugged PK: {product_id}-{component-slug}.'
+      description: "Slugged PK: {product_id}-{component-slug}."
     - name: name
       type: string
       nullable: false
@@ -2797,7 +2757,7 @@ catalogues:
     - name: kind
       type: string
       nullable: true
-      description: 'Optional classification: layout | display | input | chart | element | composite | remote | remote-iframe | remote-webcomponent. A `remote*` kind marks a micro-frontend federation seam (M-ADR 0166 §4.7).'
+      description: "Optional classification: layout | display | input | chart | element | composite | remote | remote-iframe | remote-webcomponent. A `remote*` kind marks a micro-frontend federation seam (M-ADR 0166 §4.7)."
     - name: source
       type: string
       nullable: false
@@ -2810,18 +2770,18 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "An entry in the adopter-owned component registry that screens compose against (per M-ADR 0166) — the UI-structure contract. A screen composes registry components but never defines one. Application-product profile. Source: components referenced across the SDD's screen-spec ```openui-lang blocks (registry projection); the reverse toolkit discovers the authoritative registry from the design-system import surface."
     foreign_keys:
     - column: product_id
       references: products.id
       nullable: false
   screen_component:
     primary_key: id
-    description: 'Edge: screen composes a UI component. Parsed from the screen-spec ```openui-lang block''s component references (per M-ADR 0166).'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Composite PK: {screen_id}__{component_id}.'
+      description: "Composite PK: {screen_id}__{component_id}."
     - name: screen_id
       type: string
       nullable: false
@@ -2836,6 +2796,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Edge: screen composes a UI component. Parsed from the screen-spec ```openui-lang block's component references (per M-ADR 0166)."
     foreign_keys:
     - column: screen_id
       references: screens.id
@@ -2845,12 +2806,11 @@ catalogues:
       nullable: false
   screen_feature:
     primary_key: id
-    description: 'Edge: screen realises a feature (traceability). Forward: `realises:` frontmatter on the screen-spec. Reverse: route → feature mapping. Per M-ADR 0166.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Composite PK: {screen_id}__{feature_id}. For app/integration builds the feature_id may be a bare realises slug until the aggregator resolves it to the platform feature id (then the PK is regenerated).'
+      description: "Composite PK: {screen_id}__{feature_id}. For app/integration builds the feature_id may be a bare realises slug until the aggregator resolves it to the platform feature id (then the PK is regenerated)."
     - name: screen_id
       type: string
       nullable: false
@@ -2865,6 +2825,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Edge: screen realises a feature (traceability). Forward: `realises:` frontmatter on the screen-spec. Reverse: route → feature mapping. Per M-ADR 0166."
     foreign_keys:
     - column: screen_id
       references: screens.id
@@ -2877,12 +2838,11 @@ catalogues:
       - integration-product
   persona_screen:
     primary_key: id
-    description: 'Edge: persona can access a screen. Forward: `persona_access:` frontmatter. Reverse: route persona-access guards, permission/feature-flag config, or a host shell''s per-persona menu (where the backend pre-filters visible screens). Per M-ADR 0166.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Composite PK: {persona_id}__{screen_id}.'
+      description: "Composite PK: {persona_id}__{screen_id}."
     - name: persona_id
       type: string
       nullable: false
@@ -2897,6 +2857,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Edge: persona can access a screen. Forward: `persona_access:` frontmatter. Reverse: route persona-access guards, permission/feature-flag config, or a host shell's per-persona menu (where the backend pre-filters visible screens). Per M-ADR 0166."
     foreign_keys:
     - column: persona_id
       references: personas.id
@@ -2906,12 +2867,11 @@ catalogues:
       nullable: false
   screen_action:
     primary_key: id
-    description: 'Edge: screen emits an action, optionally resolved to a catalogued event. The behavioural MFE seam — inter-bundle communication as a catalogued contract, not an ad-hoc string. Forward: `action=` declarations in the ```openui-lang block. Reverse: emitted custom-event / event-bus wiring. event_id is external-capable (the event may live in the platform SDD). Per M-ADR 0166 + M-ADR 0156.'
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'Composite PK: {screen_id}__{action-slug}.'
+      description: "Composite PK: {screen_id}__{action-slug}."
     - name: screen_id
       type: string
       nullable: false
@@ -2931,6 +2891,7 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Edge: screen emits an action, optionally resolved to a catalogued event. The behavioural MFE seam — inter-bundle communication as a catalogued contract, not an ad-hoc string. Forward: `action=` declarations in the ```openui-lang block. Reverse: emitted custom-event / event-bus wiring. event_id is external-capable (the event may live in the platform SDD). Per M-ADR 0166 + M-ADR 0156."
     foreign_keys:
     - column: screen_id
       references: screens.id
@@ -2941,7 +2902,6 @@ catalogues:
       external: true
   conformance_finding:
     primary_key: id
-    description: 'Conformance-reverse drift summary, one row per check (method M-ADR 0180). NOT produced by `catalogue build` (it reads the spec repo) — produced by `sdd-cli conformance --emit-finding` (which has the code repo) and federated here by the aggregator. Each row is a run-dated snapshot of declared-vs-observed drift for an implementation member (M-ADR 0181 role/lifecycle), so estate-wide conformance is queryable (aggregate union) and trendable (snapshot diff across runs/commits). Verdicts are PROVISIONAL — disposition (code-defect | spec-stale | divergence) is triage, recorded elsewhere. No enforced FK on implementation_repo: the code repo is frequently cross-repo and not in this SDD''s repositories.csv. Added in schema 2.25.0.'
     columns:
     - name: id
       type: string
@@ -2984,11 +2944,11 @@ catalogues:
     - name: declared_not_observed
       type: number
       nullable: false
-      description: 'Count declared but not observed (candidate: spec-stale / unimplemented / dangling).'
+      description: "Count declared but not observed (candidate: spec-stale / unimplemented / dangling)."
     - name: observed_not_declared
       type: number
       nullable: false
-      description: 'Count observed but not declared (candidate: binding-stale / code-defect).'
+      description: "Count observed but not declared (candidate: binding-stale / code-defect)."
     - name: needs_triage
       type: boolean
       nullable: false
@@ -3005,24 +2965,14 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: "Conformance-reverse drift summary, one row per check (method M-ADR 0180). NOT produced by `catalogue build` (it reads the spec repo) — produced by `sdd-cli conformance --emit-finding` (which has the code repo) and federated here by the aggregator. Each row is a run-dated snapshot of declared-vs-observed drift for an implementation member (M-ADR 0181 role/lifecycle), so estate-wide conformance is queryable (aggregate union) and trendable (snapshot diff across runs/commits). Verdicts are PROVISIONAL — disposition (code-defect | spec-stale | divergence) is triage, recorded elsewhere. No enforced FK on implementation_repo: the code repo is frequently cross-repo and not in this SDD's repositories.csv. Added in schema 2.25.0."
   quality_scores:
     primary_key: id
-    description: 'Rubric assessment of a target artefact, one row per (target, rubric), per M-ADR 0205 §4.5. Source: `orchestration/gate-registry/<rubric>-scores.yaml` — the authored surface stays YAML because a score is a judgment, authored where it asserts intent; these rows are DERIVED and never edited.
-
-      Models the EFFECTIVE score only — `current`, as chosen by the registry''s `selection_policy`. The authored `reviews[]` history is deliberately not catalogued: variable-length history in a fixed-grain catalogue would give two answers to "what is the score". `review_run_id` and `selection_method` make each row name which review it is.
-
-      THE BUILDER MUST READ TWO AUTHORED DIALECTS. All fifteen method-side templates specify a nested shape (`selection_policy` / `current` / `reviews`), but the live forward-estate data is overwhelmingly FLAT — `gate`/`weighted_score`/`scored_at`/`scored_by`/`scores`/`flags` directly on the entry. Measured 2026-08-06: reading only the template shape would catalogue 6 entries out of 204. The templates were modernised; the data was not migrated, and both are legitimate.
-
-      `rubric_id` comes from the file''s `registry_type` when declared, else the filename stem minus `-scores` — NEVER the container key, which is unreliable (4 of 10 forward registries drift from the method template) and non-unique (`domains` names both domain-architecture and intent-quality; `capabilities` names both feature-grounding and traceability-manifest).
-
-      Scope: the weighted house form only. The banded reverse family is additive later via `scoring_form` (see that enum).
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'PK: {rubric_id}__{target_kind}__{target_ref}. Composite in one slug because the natural key is a triple and the rest of this schema keys on a single `id`.'
+      description: "PK: {rubric_id}__{target_kind}__{target_ref}. Composite in one slug because the natural key is a triple and the rest of this schema keys on a single `id`."
     - name: rubric_id
       type: string
       nullable: false
@@ -3034,7 +2984,7 @@ catalogues:
     - name: target_kind
       type: string
       nullable: false
-      description: 'What kind of thing was scored: adr | contract | c4_diagram | capability | domain | feature | product | repository | persona | screen | glossary | integration | user_story | work_order | strategic_doc. Polymorphic because scored units span catalogue entities and non-catalogued artefacts (M-ADR 0205 §4.5).'
+      description: "What kind of thing was scored: adr | contract | c4_diagram | capability | domain | feature | product | repository | persona | screen | glossary | integration | user_story | work_order | strategic_doc. Polymorphic because scored units span catalogue entities and non-catalogued artefacts (M-ADR 0205 §4.5)."
     - name: target_ref
       type: string
       nullable: false
@@ -3058,19 +3008,19 @@ catalogues:
     - name: band
       type: string
       nullable: true
-      description: 'Named band for a `banded` row; empty for a weighted one. DELIBERATELY UNBOUND, and for the same reason `dimension_key` is not normalised: the vocabulary belongs to the rubric, not to the method. Measured across the reverse estate at 3.3.0 — `reverseability` uses easy | moderate | hard | very-hard (a DIFFICULTY scale, where a higher band is worse), while `repo_doc_quality`, `product_synthesis_quality`, `reverse_platform_evidence_quality` and `artifact_quality` use strong | working (a QUALITY scale). One closed enum over both would assert that `hard` and `working` are comparable, which they are not. A consumer comparing bands must therefore group by rubric_id first.'
+      description: "Named band for a `banded` row; empty for a weighted one. DELIBERATELY UNBOUND, and for the same reason `dimension_key` is not normalised: the vocabulary belongs to the rubric, not to the method. Measured across the reverse estate at 3.3.0 — `reverseability` uses easy | moderate | hard | very-hard (a DIFFICULTY scale, where a higher band is worse), while `repo_doc_quality`, `product_synthesis_quality`, `reverse_platform_evidence_quality` and `artifact_quality` use strong | working (a QUALITY scale). One closed enum over both would assert that `hard` and `working` are comparable, which they are not. A consumer comparing bands must therefore group by rubric_id first."
     - name: band_total
       type: int
       nullable: true
-      description: 'Integer total a `banded` rubric summed its dimensions to, before mapping to `band`; empty for a weighted row. Kept SEPARATE from weighted_score rather than sharing it: the scales are incompatible (a banded total ranges 0-13 against a weighted 1-5), and a single column holding both would make any average over it silently wrong. Separation makes an aggregate over weighted_score correct by construction rather than by the caller remembering to filter on scoring_form.'
+      description: "Integer total a `banded` rubric summed its dimensions to, before mapping to `band`; empty for a weighted row. Kept SEPARATE from weighted_score rather than sharing it: the scales are incompatible (a banded total ranges 0-13 against a weighted 1-5), and a single column holding both would make any average over it silently wrong. Separation makes an aggregate over weighted_score correct by construction rather than by the caller remembering to filter on scoring_form."
     - name: scored_at
       type: date
       nullable: true
-      description: 'Date of the effective assessment, from `scored_at` (the forward house form''s field name — NOT `assessed_at`, which is the reverse family''s file-level field). Date-typed: per the M-ADR 0205 §4.1 engine''s TRY_CAST semantics, a prose value here is reported as a type nonconformance rather than aborting the load or being smoothed away — the `adrs.decision_date` case, which reverse practice already exercises.'
+      description: "Date of the effective assessment, from `scored_at` (the forward house form's field name — NOT `assessed_at`, which is the reverse family's file-level field). Date-typed: per the M-ADR 0205 §4.1 engine's TRY_CAST semantics, a prose value here is reported as a type nonconformance rather than aborting the load or being smoothed away — the `adrs.decision_date` case, which reverse practice already exercises."
     - name: corpus_ref
       type: string
       nullable: true
-      description: 'The commit the assessment read — the precise staleness anchor. NEW AUTHORING introduced by this change-set: no score written before it carries one, so this column is empty across both estates at introduction and fills forward as registries are rewritten. The reverse family already has the idea under a different name (`snapshot.source_revision`).'
+      description: "The commit the assessment read — the precise staleness anchor. NEW AUTHORING introduced by this change-set: no score written before it carries one, so this column is empty across both estates at introduction and fills forward as registries are rewritten. The reverse family already has the idea under a different name (`snapshot.source_revision`)."
     - name: staleness_basis
       type: string
       nullable: false
@@ -3082,7 +3032,7 @@ catalogues:
     - name: selection_method
       type: string
       nullable: true
-      description: 'How the effective review was chosen — see the score_selection_method enum. Empty in the flat dialect, which carries no selection_policy: absence means ''the only review'', not ''policy unknown''.'
+      description: "How the effective review was chosen — see the score_selection_method enum. Empty in the flat dialect, which carries no selection_policy: absence means 'the only review', not 'policy unknown'."
     - name: scorer_provider
       type: string
       nullable: true
@@ -3106,11 +3056,11 @@ catalogues:
     - name: flag_count
       type: int
       nullable: false
-      description: 'Number of heuristic flags raised. Normalises two authored dialects: `flags: {name: bool}` (count the true ones) and `flags_raised: [names]` (count the list). A per-flag child catalogue is deliberately NOT built — it arrives when a named query needs to filter by flag name, not by accretion.'
+      description: "Number of heuristic flags raised. Normalises two authored dialects: `flags: {name: bool}` (count the true ones) and `flags_raised: [names]` (count the list). A per-flag child catalogue is deliberately NOT built — it arrives when a named query needs to filter by flag name, not by accretion."
     - name: hard_gate_triggered
       type: boolean
       nullable: false
-      description: 'Whether any hard gate fired. Normalises `hard_gates: {triggered, reasons}` and `hard_gates_triggered: [reasons]`.'
+      description: "Whether any hard gate fired. Normalises `hard_gates: {triggered, reasons}` and `hard_gates_triggered: [reasons]`."
     - name: required_actions_count
       type: int
       nullable: false
@@ -3127,22 +3077,23 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Rubric assessment of a target artefact, one row per (target, rubric), per M-ADR 0205 §4.5. Source: `orchestration/gate-registry/<rubric>-scores.yaml` — the authored surface stays YAML because a score is a judgment, authored where it asserts intent; these rows are DERIVED and never edited.
+      Models the EFFECTIVE score only — `current`, as chosen by the registry's `selection_policy`. The authored `reviews[]` history is deliberately not catalogued: variable-length history in a fixed-grain catalogue would give two answers to "what is the score". `review_run_id` and `selection_method` make each row name which review it is.
+      THE BUILDER MUST READ TWO AUTHORED DIALECTS. All fifteen method-side templates specify a nested shape (`selection_policy` / `current` / `reviews`), but the live forward-estate data is overwhelmingly FLAT — `gate`/`weighted_score`/`scored_at`/`scored_by`/`scores`/`flags` directly on the entry. Measured 2026-08-06: reading only the template shape would catalogue 6 entries out of 204. The templates were modernised; the data was not migrated, and both are legitimate.
+      `rubric_id` comes from the file's `registry_type` when declared, else the filename stem minus `-scores` — NEVER the container key, which is unreliable (4 of 10 forward registries drift from the method template) and non-unique (`domains` names both domain-architecture and intent-quality; `capabilities` names both feature-grounding and traceability-manifest).
+      Scope: the weighted house form only. The banded reverse family is additive later via `scoring_form` (see that enum).
     foreign_keys:
     - column: sdd_id
       references: products.id
       nullable: true
   quality_score_dimensions:
     primary_key: id
-    description: 'One row per (target, rubric, dimension) — the per-dimension detail behind a `quality_scores` row, per M-ADR 0205 §4.5.
-
-      A child catalogue rather than columns, and this is forced rather than stylistic: the fifteen rubrics carry FIFTEEN DISJOINT dimension vocabularies (`A1`-`A8`, `C1`-`C8`, `G1`-`G7`, `T1`-`T7`, `D1`-`D6`, `S1`-`S6`, `I1`-`I6`, plus five fully-named sets such as `definition_precision` and `intent_fidelity`) — 45 distinct keys measured in one estate alone. No fixed column set can hold them; serialised JSON in a cell would be unjoinable and break the relational metamodel; generic `d1..d8` columns would be lossy and re-create the positional-index failure class. A child table is what this metamodel already does for every one-to-many, and it joins natively on the M-ADR 0205 §4.1 engine.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'PK: {quality_score_id}__{dimension_key}.'
+      description: "PK: {quality_score_id}__{dimension_key}."
     - name: quality_score_id
       type: string
       nullable: false
@@ -3162,7 +3113,7 @@ catalogues:
     - name: dimension_key
       type: string
       nullable: false
-      description: 'The rubric''s own dimension identifier, verbatim — `A1` where the rubric uses codes, `definition_precision` where it uses names. NOT normalised into a method-wide vocabulary: the key is how the rubric and its registry refer to the dimension, and rewriting it here would make the row untraceable to the rubric that produced it.'
+      description: "The rubric's own dimension identifier, verbatim — `A1` where the rubric uses codes, `definition_precision` where it uses names. NOT normalised into a method-wide vocabulary: the key is how the rubric and its registry refer to the dimension, and rewriting it here would make the row untraceable to the rubric that produced it."
     - name: dimension_score
       type: number
       nullable: true
@@ -3170,7 +3121,7 @@ catalogues:
     - name: dimension_weight
       type: number
       nullable: true
-      description: 'Weight the rubric assigns the dimension, where discoverable. Usually EMPTY: weights live in the rubric document and the registry header comment, not per entry — so this column is honest about the fact that a weighted_score cannot currently be recomputed from these rows alone.'
+      description: "Weight the rubric assigns the dimension, where discoverable. Usually EMPTY: weights live in the rubric document and the registry header comment, not per entry — so this column is honest about the fact that a weighted_score cannot currently be recomputed from these rows alone."
     - name: source_sdd_id
       type: string
       nullable: true
@@ -3179,24 +3130,20 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      One row per (target, rubric, dimension) — the per-dimension detail behind a `quality_scores` row, per M-ADR 0205 §4.5.
+      A child catalogue rather than columns, and this is forced rather than stylistic: the fifteen rubrics carry FIFTEEN DISJOINT dimension vocabularies (`A1`-`A8`, `C1`-`C8`, `G1`-`G7`, `T1`-`T7`, `D1`-`D6`, `S1`-`S6`, `I1`-`I6`, plus five fully-named sets such as `definition_precision` and `intent_fidelity`) — 45 distinct keys measured in one estate alone. No fixed column set can hold them; serialised JSON in a cell would be unjoinable and break the relational metamodel; generic `d1..d8` columns would be lossy and re-create the positional-index failure class. A child table is what this metamodel already does for every one-to-many, and it joins natively on the M-ADR 0205 §4.1 engine.
     foreign_keys:
     - column: quality_score_id
       references: quality_scores.id
       nullable: false
   scaffolds:
     primary_key: id
-    description: 'Forward scaffold declaration, one row per unit of work, per M-ADR 0207 §4.1. Source: `orchestration/scaffolds/*.yaml` — the authored surface stays YAML because a scaffold is a declaration of intent, authored where the work is scoped; these rows are DERIVED and never edited (M-ADR 0205 §4.0 governs unchanged).
-
-      The scaffold states the catalogue shape a unit of work will comprise — its items are `scaffold_items` rows — and the declared-vs-derived delta against the built catalogues is the unit''s definition of done: delta zero (structural) AND every realised artefact score-current (content, via `quality_scores`), per M-ADR 0207 §4.5. The unit is the change-set''s declared delta; estate-level scaffold totality is an explicit non-goal (M-ADR 0207 §4.4), so an estate region no scaffold covers produces no finding.
-
-      `corpus_ref` is REQUIRED — a scaffold without an anchor cannot carry a staleness verdict, and M-ADR 0207 §4.6 makes the anchor part of the declaration, not an optional refinement. Staleness itself is computed at coverage time (the scores idiom), never stored here.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'PK: the manifest''s declared unit id (kebab-case slug). Unique per SDD; the aggregator namespaces cross-SDD ids exactly as for every other catalogue.'
+      description: "PK: the manifest's declared unit id (kebab-case slug). Unique per SDD; the aggregator namespaces cross-SDD ids exactly as for every other catalogue."
     - name: name
       type: string
       nullable: false
@@ -3212,7 +3159,7 @@ catalogues:
     - name: corpus_ref
       type: string
       nullable: false
-      description: 'The commit the scaffold was declared against — the staleness anchor, mirroring quality_scores.corpus_ref (M-ADR 0207 §4.6: one staleness idiom, not two). Required: a manifest without one fails validation rather than emitting an unanchorable row.'
+      description: "The commit the scaffold was declared against — the staleness anchor, mirroring quality_scores.corpus_ref (M-ADR 0207 §4.6: one staleness idiom, not two). Required: a manifest without one fails validation rather than emitting an unanchorable row."
     - name: manifest_schema
       type: string
       nullable: false
@@ -3229,6 +3176,10 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      Forward scaffold declaration, one row per unit of work, per M-ADR 0207 §4.1. Source: `orchestration/scaffolds/*.yaml` — the authored surface stays YAML because a scaffold is a declaration of intent, authored where the work is scoped; these rows are DERIVED and never edited (M-ADR 0205 §4.0 governs unchanged).
+      The scaffold states the catalogue shape a unit of work will comprise — its items are `scaffold_items` rows — and the declared-vs-derived delta against the built catalogues is the unit's definition of done: delta zero (structural) AND every realised artefact score-current (content, via `quality_scores`), per M-ADR 0207 §4.5. The unit is the change-set's declared delta; estate-level scaffold totality is an explicit non-goal (M-ADR 0207 §4.4), so an estate region no scaffold covers produces no finding.
+      `corpus_ref` is REQUIRED — a scaffold without an anchor cannot carry a staleness verdict, and M-ADR 0207 §4.6 makes the anchor part of the declaration, not an optional refinement. Staleness itself is computed at coverage time (the scores idiom), never stored here.
     foreign_keys:
     - column: sdd_id
       references: products.id
@@ -3237,18 +3188,11 @@ catalogues:
       status: enums.scaffold_status
   scaffold_items:
     primary_key: id
-    description: 'One declared item of a scaffold — an entity, edge, or contract the unit of work promises — per M-ADR 0207 §4.1. Derived from the manifest''s item list; `state` is the builder''s resolution verdict against the same build''s catalogue rows.
-
-      THE POLYMORPHIC TARGET DECLARES NO FOREIGN KEY, by design (the quality_scores.target_ref precedent, taken further): a scaffold exists to reference targets BEFORE they exist. FK truth here is CONDITIONAL ON STATE — a `declared` item''s (target_kind, target_ref) MUST NOT resolve in the built catalogues, a `realised` item''s MUST — and the builder''s resolution pass is what enforces it: it computes `state` FROM resolution, so a disagreement between state and resolution cannot be emitted by a conforming builder. The M-ADR 0207 §4.8 delta instrument re-derives the same verdict on the engine as its self-check.
-
-      `target_kind` is the CATALOGUE NAME the target should appear in (services, capabilities, repo_contract, contracts, …) — bound to the schema''s own catalogue list by the builder: an unknown target_kind is a loud convention finding, never a silently-dropped item (M-ADR 0207 §4.1). For `edge` items the endpoints are declared in edge_source_ref/edge_target_ref, mapped to the edge catalogue''s FK columns in schema declaration order; target_ref then carries the builder-computed endpoint slug so the PK stays single-column.
-
-      '
     columns:
     - name: id
       type: string
       nullable: false
-      description: 'PK: {scaffold_id}__{item_kind}__{target_kind}__{target_ref}. Composite in one slug because the natural key is a quadruple and the rest of this schema keys on a single `id`.'
+      description: "PK: {scaffold_id}__{item_kind}__{target_kind}__{target_ref}. Composite in one slug because the natural key is a quadruple and the rest of this schema keys on a single `id`."
     - name: scaffold_id
       type: string
       nullable: false
@@ -3264,15 +3208,15 @@ catalogues:
     - name: target_ref
       type: string
       nullable: false
-      description: 'Identifier of the declared target in the vocabulary of its catalogue: the declared id for entity items, the repo-relative spec path for contract items (matching contracts.spec_path), the builder-computed {source}__{target} endpoint slug for edge items.'
+      description: "Identifier of the declared target in the vocabulary of its catalogue: the declared id for entity items, the repo-relative spec path for contract items (matching contracts.spec_path), the builder-computed {source}__{target} endpoint slug for edge items."
     - name: edge_source_ref
       type: string
       nullable: true
-      description: 'For edge items: the declared source endpoint, in the vocabulary of the edge catalogue''s first FK column (schema declaration order). Empty for entity and contract items.'
+      description: "For edge items: the declared source endpoint, in the vocabulary of the edge catalogue's first FK column (schema declaration order). Empty for entity and contract items."
     - name: edge_target_ref
       type: string
       nullable: true
-      description: 'For edge items: the declared target endpoint, second FK column. Empty for entity and contract items.'
+      description: "For edge items: the declared target endpoint, second FK column. Empty for entity and contract items."
     - name: state
       type: string
       nullable: false
@@ -3285,6 +3229,10 @@ catalogues:
       type: string
       nullable: true
       description: The platform this row belongs to — sdd_id of its platform-root. Stamped by the aggregator per M-ADR 0208 §4.4 (preserve-if-set, fill rule by pull path); left empty by per-SDD builders. Added in 3.7.0.
+    description: |
+      One declared item of a scaffold — an entity, edge, or contract the unit of work promises — per M-ADR 0207 §4.1. Derived from the manifest's item list; `state` is the builder's resolution verdict against the same build's catalogue rows.
+      THE POLYMORPHIC TARGET DECLARES NO FOREIGN KEY, by design (the quality_scores.target_ref precedent, taken further): a scaffold exists to reference targets BEFORE they exist. FK truth here is CONDITIONAL ON STATE — a `declared` item's (target_kind, target_ref) MUST NOT resolve in the built catalogues, a `realised` item's MUST — and the builder's resolution pass is what enforces it: it computes `state` FROM resolution, so a disagreement between state and resolution cannot be emitted by a conforming builder. The M-ADR 0207 §4.8 delta instrument re-derives the same verdict on the engine as its self-check.
+      `target_kind` is the CATALOGUE NAME the target should appear in (services, capabilities, repo_contract, contracts, …) — bound to the schema's own catalogue list by the builder: an unknown target_kind is a loud convention finding, never a silently-dropped item (M-ADR 0207 §4.1). For `edge` items the endpoints are declared in edge_source_ref/edge_target_ref, mapped to the edge catalogue's FK columns in schema declaration order; target_ref then carries the builder-computed endpoint slug so the PK stays single-column.
     foreign_keys:
     - column: scaffold_id
       references: scaffolds.id