Resolve glossary runtime views while retaining business logic

docs/roadmap/configkit.md

@@ -139,7 +139,7 @@ file remain terminal.
    [extensible entry content contract](glossary-stages.md#entry-content-fields--resolved)
    using native typed fields and inline extension data.
    Complete its required durable decision record. The glossary roadmap owns
-   the remaining runtime-view, selection-input, and attribution decisions. This
+   the remaining selection-input and attribution decisions. This
    application scope model does not change native source composition or
    sibling-inheritance semantics.
 

docs/roadmap/glossary-stages.md

@@ -28,7 +28,8 @@ Finalize the glossary representation with the agreed
 [version-3 application schema](configkit.md#application-schema-version--resolved)
 so operators migrate once. Collection placement and named selection are selected;
 default import sources, their tier, entry identity, and content fields are also
-selected. Runtime ambiguity and remaining selection details are open below.
+selected. Runtime ordering and deduplication are selected below, with existing
+business logic retained. Remaining selection and attribution details are open.
 
 ## Glossary Configuration Ownership — Resolved
 
@@ -104,7 +105,8 @@ filenames or subdirectories; all matches of the declaration receive the same
 destination. Moving a file within the imported tree therefore need not change
 stage selections. A file can define multiple collections, and multiple sources
 can contribute to one collection under native composition and identity rules.
-Repeated membership and runtime entry ordering remain domain decisions below.
+Repeated membership and runtime entry ordering follow the resolved runtime
+vocabulary rules below.
 
 Use native mapping placement, discovery, composition, and provenance. Do not add
 a directory walker, filename-to-key conversion, or YAML preprocessing in Audita.
@@ -331,9 +333,33 @@ multiple valid records contribute the same recognized spelling. Do not use the
 latter to suppress configuration conflicts or rewrite the resolved definitions.
 Rich prompt data need not lose distinct definitions merely because their text
 matches in the protection view. Audita owns matching, transcript-specific
-validation, and the selected stage-specific transformations. Detailed handling
-of ambiguous identities, repeated membership, and rich-entry ordering remains
-open below.
+validation, and the selected stage-specific transformations. Apply the runtime
+vocabulary rules below while retaining existing business logic.
+
+### Runtime Vocabulary and Ordering — Resolved
+
+Retain distinct resolved entries in rich LLM input, even when names or other
+content match. Two entries named Shield may describe a spell and an item; both
+can supply useful context. Matching text does not merge configuration identities.
+
+Include each selected entry once, identified by `(collection name, id)`. Traverse
+collections in selection order and entries in their resolved ConfigKit order.
+Keep the first occurrence when selection repeats an entry. Separate records
+remain separate even when their content is identical. These rules govern runtime
+projections without rewriting the configured selections or definitions.
+
+Deduplicate recognized spellings in protected vocabulary using the existing
+matcher rules. Repeated membership must not multiply protection requirements.
+Retain the association between each spelling and all contributing entries so
+vocabulary deduplication does not discard identity information.
+
+Preserve the current business logic for overlapping terms, ambiguous aliases,
+and identity-dependent validation, including protected-name repetition handling.
+This decision changes representation and traversal, not those validation rules.
+Carry forward the previously selected stage-selection and active-term exemption
+model without introducing a new blanket exemption for spellings shared by distinct
+identities. Verify existing behavior when connecting the new runtime views to
+consumers; redesigning overlap or ambiguity handling is outside this change.
 
 ## Root Defaults and Stage Overrides — Resolved
 
@@ -408,8 +434,8 @@ An explicit protection selection is complete, not an additive set of extra
 vocabulary. Do not implicitly union it with correction inputs or collections
 selected by other stages.
 
-The named mapping and ordered name selections are selected above. Entry identity,
-repeated membership, and rich-input order remain open. Configuration composition
+The named mapping, ordered name selections, entry identity, repeated membership,
+and rich-input order are selected above. Configuration composition
 must follow ConfigKit's contracts rather than a local rule to concatenate
 independently parsed files.
 
@@ -443,9 +469,9 @@ The table assumes distinct party and spell vocabulary. The subtraction applies
 after resolving both stage selections, including explicit protection overrides.
 It operates on recognized terms using the protection matcher's rules, including
 names, aliases, and supported plural forms, rather than subtracting configuration
-source files or collection names. Terms shared across collections participate in
-the same operation; shared spellings associated with different identities remain
-part of the overlap decision below.
+source files or collection names. For shared spellings associated with different
+identities, preserve existing business logic under the runtime vocabulary
+decision above.
 
 Keep the configured protection selection intact and construct the reduced
 vocabulary separately for that stage. Do not mutate root settings, loaded
@@ -466,7 +492,6 @@ Use the active-term exemption for glossary correction and retain the existing
 module-appropriate allowance for spoken-word cleanup. Carry both selections
 through execution and validation rather than passing a single combined glossary
 to every consumer.
-Runtime overlap and payload details remain open below.
 
 ### Validation-Profile Fallback — Resolved
 
@@ -734,7 +759,12 @@ Verify that distinct valid definitions can contribute to a deduplicated runtime
 vocabulary without rewriting rich configured entries. Check that rich LLM input
 contains the selected descriptive fields, and that deriving or using any runtime
 view leaves configuration and other consumers' views unchanged. Verify the
-selected rules for repeated membership, entry ordering, and ambiguous spellings.
+selected rules for repeated membership and entry ordering: first occurrence of
+each `(collection name, id)` wins, while separate records with matching names or
+content remain distinct. Verify that deduplicated spellings retain all contributing
+entry associations and do not multiply protection requirements. Preserve existing
+overlap, ambiguous-alias, and protected-name repetition behavior when adapting
+consumers to these views.
 
 Exercise the selected request and validation overrides through stage consumers,
 including independent budgets without changing shared backend admission or the
@@ -752,7 +782,8 @@ empty CLI values where valid, and the absence of overrides from parser defaults.
 Cover root protection defaulting after CLI assignment, explicit root protection
 surviving glossary overrides, and recorded root-to-stage protection dependencies.
 Verify module-appropriate protection using terminology from both collections, including
-legitimate corrections and cleanup; test the selected overlap/conflict behavior.
+legitimate corrections and cleanup; retain regression coverage for existing
+overlap and ambiguity behavior.
 For glossary stages, verify that active terms are exempt while remaining selected
 terms stay protected, including when protection was explicitly configured.
 Cover names, aliases, supported plurals, and vocabulary shared across collections.
@@ -767,25 +798,6 @@ guidance are in place before declaring this feature complete.
 
 The recommendations below are proposals, not selected contracts.
 
-### Runtime Vocabulary and Identity Ambiguity
-
-**Recommendation:** deduplicate recognized spellings for protection using the
-same matching rules as active-term subtraction, while retaining distinct resolved
-entry identities and rich data. Repeated membership must not multiply protection.
-For checks that depend on identity, do not infer equivalence or grant a relaxation
-solely because entries share an alias; define conservative behavior for ambiguous
-matches. Specify deterministic rich-input ordering and whether repeated selection
-of the same resolved entry appears once. This preserves useful context without
-turning runtime deduplication into configuration conflict resolution, but requires
-focused decisions and tests around identity-dependent cleanup.
-
-**Alternative:** reject ambiguous names or aliases at domain validation time.
-This simplifies deterministic identity checks, but disallows legitimate shared
-spellings and burdens authors of reusable collections. Native ConfigKit record
-identity checks remain authoritative in either case; they do not determine which
-meaning a transcript occurrence has. The active-glossary exemption itself is
-already selected and is not reopened by this decision.
-
 ### List Inputs and CLI Representation
 
 **Recommendation:** accept explicit null as an empty selection, preserving native