Add capability registry scaffold and seed entries from reuse-surface

Bootstrap registry/indexes/capabilities.yaml and migrate helix_forge
capability entries owned by this repository for federation publishing.

registry/README.md

@@ -0,0 +1,12 @@
+# Capability Registry
+
+Markdown-first capability index for federation and reuse planning.
+
+## Authoring
+
+1. Copy a capability entry template (see reuse-surface `templates/capability-entry.template.md`).
+2. Add the row to `indexes/capabilities.yaml`.
+3. Run `reuse-surface validate` from a checkout with the CLI installed.
+4. Merge to `main` and verify publish with `reuse-surface establish --publish-check`.
+
+Federation contract: reuse-surface `docs/RegistryFederation.md`.

registry/capabilities/capability.identity.subject-resolution.md

@@ -0,0 +1,115 @@
+---
+id: capability.identity.subject-resolution
+name: Identity Subject Resolution
+summary: Resolve who or what is acting in a context by mapping principals, accounts, actors, and identifiers to a stable subject model.
+owner: identity-canon
+status: draft
+domain: helix_forge
+tags:
+  - identity
+  - subject
+  - architecture
+
+maturity:
+  discovery:
+    current: D3
+    target: D5
+    confidence: medium
+    rationale: >
+      Subject/principal terminology is explored in identity-canon conflict maps
+      and conceptual model, but dedicated use-case grounding is incomplete.
+  availability:
+    current: A0
+    target: A4
+    confidence: low
+    rationale: >
+      Canon and research artifacts exist; no standalone resolver service or SDK
+      is registered yet.
+
+external_evidence:
+  completeness:
+    level: C1
+    name: Fragmentary
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+      - overloaded subject and principal terms are mapped as candidates
+    broken_expectations:
+      - no runtime resolver artifact
+      - canonical subject model not finalized across all actor types
+    out_of_scope_expectations:
+      - authentication protocol implementation
+      - credential storage
+  reliability:
+    level: R0
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+      - draft terminology may change during source-note backfill
+
+discovery:
+  intent: >
+    Give planners and implementers a consistent subject concept for authorization,
+    feature control, tenancy, and agent workflows without collapsing product-specific
+    identity models.
+  includes:
+    - subject vs principal vs account distinctions
+    - actor type modeling
+    - identifier resolution concepts
+  excludes:
+    - authentication execution
+    - credential issuance
+    - directory provisioning
+  assumptions:
+    - vocabulary canonicalization supports but does not replace subject resolution
+  use_cases:
+    - UC-RS-004
+  research_memos:
+    - identity-canon/terminology/TerminologyConflictMap.md
+    - identity-canon/model/ConceptualModel.md
+
+availability:
+  current_level: A0
+  target_level: A4
+  current_artifacts:
+    - identity-canon/model/ConceptualModel.md
+    - identity-canon/canon/CanonicalGlossary.md
+  target_artifacts:
+    - identity-canon/packages/subject-resolution-sdk
+  consumption_modes:
+    - informational
+
+relations:
+  depends_on:
+    - capability.identity.vocabulary-canonicalize
+  supports:
+    - capability.feature-control.evaluate
+    - capability.statehub.workstream-coordinate
+  related_to: []
+
+evidence:
+  documentation:
+    - identity-canon/canon/CanonicalGlossary.md
+    - identity-canon/scenarios/ScenarioTests.md
+  tests: []
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+
+consumer_guidance:
+  recommended_for:
+    - architecture planning where subject/principal/account terms overlap
+  not_recommended_for:
+    - runtime authentication or token validation
+    - treating draft canon as finalized resolver behavior
+  known_limitations:
+    - resolver artifacts are not yet available
+---
+
+# Identity Subject Resolution
+
+## Overview
+
+Subject resolution defines how actors and identifiers map to a stable subject
+concept for downstream capabilities such as feature evaluation and coordination.
+Today this capability is planning-heavy (D3/A0).

registry/capabilities/capability.identity.vocabulary-canonicalize.md

@@ -0,0 +1,136 @@
+---
+id: capability.identity.vocabulary-canonicalize
+name: Identity Vocabulary Canonicalization
+summary: Define and maintain an implementation-neutral vocabulary for identity-related concepts across overlapping domains.
+owner: identity-canon
+status: draft
+domain: helix_forge
+tags:
+  - identity
+  - terminology
+  - research
+
+maturity:
+  discovery:
+    current: D4
+    target: D6
+    confidence: medium
+    rationale: >
+      identity-canon has researched overlapping terminology across IAM,
+      directory, federation, and authorization domains, but use-case saturation
+      is not yet demonstrated.
+  availability:
+    current: A0
+    target: A2
+    confidence: medium
+    rationale: >
+      The capability is available as research and canon documentation only.
+      Future source modules or libraries could raise availability to A2.
+
+external_evidence:
+  completeness:
+    level: C2
+    name: Partial
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+      - draft canonical glossary exists
+      - terminology conflict map exists
+      - conceptual model and scenario tests exist
+    broken_expectations:
+      - individual source notes are not fully backfilled
+      - many mappings remain candidate rather than finalized
+    out_of_scope_expectations:
+      - operating identity providers
+      - provisioning or authorization engines
+  reliability:
+    level: R0
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+      - draft canon terms may change as source evidence is backfilled
+
+discovery:
+  intent: >
+    Provide a reusable planning primitive for identity vocabulary so architects
+    and agents can compare overlapping terms consistently without collapsing
+    product-specific meanings into one ambiguous label.
+  includes:
+    - canonical glossary maintenance
+    - terminology conflict mapping
+    - conceptual model and scenario tests
+    - research corpus indexing
+  excludes:
+    - identity provider implementation
+    - account lifecycle services
+    - authorization policy enforcement
+  assumptions:
+    - external product mappings remain separate from canonical definitions
+  use_cases:
+    - UC-RS-004
+    - UC-RS-006
+  research_memos:
+    - identity-canon/ResearchProposal.md
+    - identity-canon/canon/CanonicalGlossary.md
+
+availability:
+  current_level: A0
+  target_level: A2
+  current_artifacts:
+    - identity-canon/canon/CanonicalGlossary.md
+    - identity-canon/terminology/TerminologyConflictMap.md
+    - identity-canon/model/ConceptualModel.md
+  target_artifacts:
+    - identity-canon/packages/identity-vocabulary
+  consumption_modes:
+    - informational
+    - markdown research artifacts
+
+relations:
+  depends_on: []
+  supports:
+    - capability.feature-control.evaluate
+    - capability.registry.register
+  related_to:
+    - capability.identity.subject-resolution
+
+evidence:
+  documentation:
+    - identity-canon/INTENT.md
+    - identity-canon/canon/CanonicalGlossary.md
+  tests: []
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+
+consumer_guidance:
+  recommended_for:
+    - architecture and planning conversations involving overloaded identity terms
+    - comparing IAM, directory, and authorization vocabulary without forcing one product model
+  not_recommended_for:
+    - runtime identity resolution
+    - assuming draft canon entries are finalized standards
+  known_limitations:
+    - source-note backfill is incomplete
+    - mappings may remain candidate until evidence review completes
+---
+
+# Identity Vocabulary Canonicalization
+
+## Overview
+
+This capability makes identity vocabulary reusable for planning across adjacent
+domains. It is intentionally research-heavy and informational, illustrating a
+D4/A0/C2/R0 vector that contrasts with implementation-ready entries.
+
+## Current reuse mode
+
+Consumers read canon, terminology, and model artifacts in the identity-canon
+repository. The value is planning reuse through shared vocabulary, not runtime
+integration.
+
+## Relation to adjacent capabilities
+
+Feature-control evaluation depends on consistent subject and tenant concepts.
+This capability supports that planning layer without providing runtime identity
+services itself.

registry/indexes/capabilities.yaml

@@ -0,0 +1,34 @@
+version: 1
+updated: '2026-06-16'
+domain: helix_forge
+capabilities:
+- id: capability.identity.subject-resolution
+  name: Identity Subject Resolution
+  summary: Resolve who or what is acting by mapping principals, accounts, actors,
+    and identifiers to a stable subject model.
+  vector: D3 / A0 / C1 / R0
+  domain: helix_forge
+  status: draft
+  owner: identity-canon
+  path: registry/capabilities/capability.identity.subject-resolution.md
+  tags:
+  - identity
+  - subject
+  - architecture
+  consumption_modes:
+  - informational
+- id: capability.identity.vocabulary-canonicalize
+  name: Identity Vocabulary Canonicalization
+  summary: Define an implementation-neutral vocabulary for identity-related concepts
+    across overlapping domains.
+  vector: D4 / A0 / C2 / R0
+  domain: helix_forge
+  status: draft
+  owner: identity-canon
+  path: registry/capabilities/capability.identity.vocabulary-canonicalize.md
+  tags:
+  - identity
+  - terminology
+  - research
+  consumption_modes:
+  - informational