## Migration Verdict **BLOCK** **Executive rationale:** `customerEmail` is removed and replaced by `primaryContact` with no stable identifier or explicit mapping connecting the two. Per policy, a rename is only compatible when both identifier continuity and value semantics are preserved — here neither holds: `primaryContact` is polymorphic (email, phone, or messaging handle), while every downstream consumer that touched `customerEmail` assumed a single-valued email string. This is not a rename; it is a removal plus an unrelated new property with overlapping but broader semantics. The campaign tool's hard requirement that no phone or messaging identifiers reach it makes this a policy violation risk, not just a compatibility gap. **Blocking conditions:** - No stable identifier or mapping links `customerEmail` → `primaryContact` - `primaryContact`'s value space (email | phone | messaging handle) violates the value-semantics-preservation requirement in policy - Campaign tool's explicit exclusion of phone/messaging identifiers cannot be enforced without a type discriminator on `primaryContact` - All four dependent consumer classes (SPARQL queries, CRM exports, email-validation tools, prompt examples) reference the retired identifier directly **Confidence level:** High for the breaking/policy-violation classification (based on explicit inputs). Low for downstream blast radius — exact query/export/tool counts are not enumerated. **Missing evidence that could change the verdict:** A type discriminator or subtype (e.g., `primaryContact.contactType`) on `primaryContact`; a stable ID or `owl:sameAs`-style mapping from `customerEmail`; confirmation of how many CRM exports/queries exist and whether they can be updated pre-cutover. ## Assumptions **Confirmed facts:** - `customerEmail` was a stable property on Customer, used as contact identifier - `MarketingCampaign` reaches Customer via `hasRecipient` - Candidate removes `customerEmail`, introduces `primaryContact` (email/phone/messaging, unconstrained) - No mapping or stable identifier supplied - SPARQL queries, CRM exports, email-validation tools, and prompt examples reference `customerEmail` - Campaign tool assumes all values are valid emails - Policy requires stable identifiers for compatible renames and forbids campaign tools receiving non-email identifiers **Audit assumptions:** - `hasRecipient` relation itself is unchanged (not stated as modified) - "Campaign tool" in Dependencies is the same consumer as the "Campaign tools" clause in Policy **Missing evidence:** - Whether `primaryContact` has any sub-typing or format discriminator - Count/identity of specific SPARQL queries, CRM export jobs, and prompt examples affected - Whether email-validation tool fails closed or open on non-email input - Owner/steward of the Customer class or of this change **Prohibited assumptions not made:** - Did not assume `primaryContact` is a rename of `customerEmail` despite label proximity in meaning - Did not assume existing data will be back-filled or migrated - Did not assume the campaign tool has been updated to filter by contact type - Did not treat absence of a mapping as evidence of compatibility ## Semantic Change Ledger | ID | Element | Namespace | Baseline state | Candidate state | Change type | Classification | Evidence | Affected consumers | Required action | |---|---|---|---|---|---|---|---|---|---| | SC-01 | customerEmail | Customer | Stable property, contact identifier, email-typed | Removed | Removed | BREAKING | Candidate model omits property; no mapping supplied | SPARQL queries, CRM exports, email-validation tools, prompt examples, campaign tool | Restore stable identifier or supply explicit mapping before cutover | | SC-02 | primaryContact | Customer | Not present | New property, value may be email, phone, or messaging handle | Added | BEHAVIOR_CHANGE / SECURITY_RELEVANT | Candidate model text | Campaign tool (policy-restricted), CRM exports | Add type discriminator; enforce email-only filter at consumption points | | SC-03 | customerEmail → primaryContact (claimed rename) | Customer | orderTotal-style rename pattern claimed by label similarity | No identifier/mapping continuity | Redefined (label collision, not true rename) | BREAKING | No stable ID or mapping field present in either model | All contact-identifier consumers | Do not treat as rename; require explicit migration mapping | ## Collision Report | Term | Namespace A meaning | Namespace B meaning | Collision type | Behavioral risk | Security risk | Resolution | |---|---|---|---|---|---|---| | customerEmail / primaryContact | Baseline: single-purpose, email-typed contact identifier | Candidate: polymorphic contact value (email/phone/messaging) | Same-concept, broadened value semantics, no identifier continuity | High — consumers expecting email string get untyped/mixed data | Yes — campaign tool policy explicitly forbids phone/messaging reaching it; broadened type risks policy violation if unfiltered | Introduce discriminated union or subtype property; require explicit mapping with type constraint before rename can be considered compatible | Checked remaining namespace elements (`hasRecipient`, `MarketingCampaign`, `Customer` class itself) — no additional collisions found. NONE beyond the row above. ## Answerability Delta | Question or capability | Baseline resolution | Candidate resolution | Changed path | Evidence | Regression status | Required fix | |---|---|---|---|---|---|---| | "What is Customer X's email?" | Direct resolution via `customerEmail` | No direct resolution; `primaryContact` may not be an email | `customerEmail` → `primaryContact` (untyped) | Property removed, no mapping | Failed | Add discriminator so email-specific queries can filter `primaryContact` by type, or restore `customerEmail` as derived/alias property | | "Send campaign to Customer X via email" | `hasRecipient` → `customerEmail`, assumed valid email | `hasRecipient` → `primaryContact`, type unknown | Traversal endpoint changed from typed to untyped | Campaign tool dependency + policy statement | Failed | Enforce email-type filter before campaign tool consumption; block non-email values at query time | | "Export customer contact list to CRM" | Exports `customerEmail` field | Field no longer exists; export mapping breaks | `customerEmail` reference orphaned | CRM export dependency listed | Failed | Update export mapping to target `primaryContact` with explicit type filter | ## Dependency Impact | Consumer type | Consumer name | Affected identifier or path | Impact | Required update | Owner if known | Verification method | |---|---|---|---|---|---|---| | Query | SPARQL queries (unspecified set) | `customerEmail` | Query fails / returns empty on removed property | Rewrite to target `primaryContact` with type filter | Unknown | Run existing query suite against candidate model | | Export | CRM exports | `customerEmail` | Export field orphaned | Remap export schema field | Unknown | Diff export output pre/post migration | | Tool | Email-validation tools | `customerEmail` | Input source removed; tool may receive non-email values via `primaryContact` if remapped naively | Add pre-validation type filter | Unknown | Feed sample `primaryContact` values (email/phone/handle) and confirm correct accept/reject | | Tool | Campaign tool | `hasRecipient` → contact value | Policy violation risk: may receive phone/messaging identifiers | Enforce email-only filter at ingestion; reject non-email `primaryContact` values | Unknown | Adversarial test with phone/handle values in `primaryContact`, confirm rejection | | Prompt/Example | Prompt examples referencing `customerEmail` | `customerEmail` | Examples reference retired identifier; will produce invalid or hallucinated field references | Update all examples to `primaryContact` with explicit type assumption stated | Unknown | Manual/automated scan of prompt corpus for `customerEmail` references | ## Security Review - **New semantic traversal path:** `hasRecipient` now terminates at a polymorphic `primaryContact` rather than a strictly-typed email property — this widens the accessible information shape at that traversal endpoint from "email string" to "email, phone, or messaging handle." - **Removed/redirected paths:** The `customerEmail`-typed path is removed outright; any access control or filtering logic keyed to that property's type is now orphaned. - **Namespace boundary changes:** None indicated beyond the Customer class itself. - **Relation changes expanding accessible information:** Yes — `hasRecipient` → `primaryContact` can now expose phone numbers and messaging handles to any consumer that previously only received email addresses via this path. This is the core SECURITY_RELEVANT finding. - **Authorization assumptions invalidated:** The campaign tool's implicit trust boundary ("this path only ever yields emails") is broken. If the campaign tool has no independent type check, this is a direct policy violation, not just a data-quality issue. - **Isolation risks:** If phone/messaging identifiers are more sensitive or governed differently than email (common in PII regimes), this traversal-path change may cross a data-classification boundary without corresponding controls. - **Permission inheritance concerns:** None identified from supplied inputs — no permission model was provided for `primaryContact`. - **Evidence supporting each finding:** Directly stated in Candidate Semantic Model (polymorphic value) and Policy (explicit prohibition on campaign tools receiving phone/messaging identifiers). - **Security gaps requiring human review:** Confirm whether any existing access-control or data-classification layer keys off property type (`customerEmail` vs `primaryContact`) rather than relation (`hasRecipient`), since removing the typed property may silently bypass such controls. ## Provenance and Governance Gaps | Element | Missing metadata | Why it matters | Required owner | Resolution | |---|---|---|---|---| | primaryContact | Stable identifier / mapping from customerEmail | Without it, rename vs. removal-plus-addition cannot be distinguished; blocks safe migration | Unknown | Assign stable ID or explicit `owl:sameAs`/mapping annotation | | primaryContact | Value-type discriminator / subtype | Required to enforce policy (campaign tool must not receive phone/messaging) | Unknown | Add `contactType` or split into `primaryEmail`/`primaryPhone`/`primaryHandle` | | customerEmail (removal) | Change rationale, approval record, effective date | Needed to confirm this is an intentional, governed change vs. accidental drift | Unknown | Record change ticket/approval reference | | Customer class | Steward/owner | No owner supplied for either property | Unknown | Assign steward for contact-data governance | ## Migration Plan 1. **Objective:** Establish identifier continuity between `customerEmail` and `primaryContact`. **Model change:** Add stable mapping/identifier or `owl:sameAs`-equivalent annotation linking the two properties. **Consumer update:** None yet. **Mapping/compatibility action:** Define explicit mapping rule. **Version pinning requirement:** Pin all consumers to baseline model until mapping exists. **Validation gate:** Mapping reviewed and confirmed by data owner. **Rollback trigger:** Mapping cannot be established without data loss. **Rollback action:** Retain `customerEmail` in parallel. **Responsible role:** Model/ontology owner (unknown). 2. **Objective:** Add type discriminator to `primaryContact`. **Model change:** Introduce `contactType` enum (email | phone | messaging) or split into typed subproperties. **Consumer update:** Email-validation tools and campaign tool updated to filter on type. **Mapping/compatibility action:** Define default/fallback behavior for untyped legacy data. **Version pinning requirement:** Candidate model not promoted until discriminator exists. **Validation gate:** Adversarial test confirms campaign tool rejects non-email values. **Rollback trigger:** Discriminator cannot be reliably populated for existing data. **Rollback action:** Block campaign tool from `primaryContact` entirely until resolved. **Responsible role:** Ontology owner + campaign tool owner (unknown). 3. **Objective:** Update dependent consumers. **Model change:** None (consumer-side only). **Consumer update:** Rewrite SPARQL queries, CRM export mappings, prompt examples to target `primaryContact` + type filter. **Mapping/compatibility action:** Provide compatibility shim (virtual `customerEmail` property derived from typed `primaryContact`) during transition. **Version pinning requirement:** Run dual-write or shim period. **Validation gate:** Full regression suite (below) passes against updated consumers. **Rollback trigger:** Any consumer fails validation against shim. **Rollback action:** Extend shim period; do not retire `customerEmail` path. **Responsible role:** Each consumer's respective owner (unknown). 4. **Objective:** Cutover and retirement of `customerEmail`. **Model change:** Remove `customerEmail` from baseline once shim is no longer needed. **Consumer update:** Confirm zero remaining references. **Mapping/compatibility action:** Archive mapping record for audit trail. **Version pinning requirement:** All consumers on candidate model. **Validation gate:** Full regression suite passes with `customerEmail` absent. **Rollback trigger:** Any orphaned reference discovered post-cutover. **Rollback action:** Restore `customerEmail` from archived mapping. **Responsible role:** Ontology owner (unknown). ## Regression Suite | Test ID | Scenario | Input or query | Baseline expectation | Candidate expectation | Pass condition | |---|---|---|---|---|---| | RT-01 | Positive resolution | Query Customer's email via `customerEmail` | Returns email string | Property absent | Fails on candidate — confirms breaking change until mapping added | | RT-02 | Negative/prohibited path | Campaign tool queries `hasRecipient` → `primaryContact` where value is a phone number | N/A (baseline had no such case) | Campaign tool must reject/exclude non-email value | Test passes only if non-email values are filtered out before reaching campaign send logic | | RT-03 | Legacy identifier | Existing SPARQL query referencing `customerEmail` | Resolves normally | Query fails or returns empty | Must fail loudly (not silently) so consumers detect breakage | | RT-04 | Rename/mapping case | Query using proposed mapping annotation to resolve `customerEmail` → `primaryContact` | N/A | Resolves to correct `primaryContact` value once mapping exists | Passes only after SC-01/SC-03 remediation (mapping step 1 of migration plan) | | RT-05 | Collision/namespace | Check for any other property in Customer namespace colliding with `primaryContact` label or meaning | N/A | No collision found in supplied model | Passes if scan confirms no additional collisions | | RT-06 | Cardinality/hierarchy | Confirm `primaryContact` cardinality (single vs. multi-valued) vs. baseline `customerEmail` | Single-valued (implied) | Not specified in candidate | Fails as UNKNOWN — cardinality must be confirmed and tested explicitly | | RT-07 | Metric/aggregation | N/A — no metrics defined on this property pair | N/A | N/A | Not applicable; no metric definitions present in either model | | RT-08 | Orphaned mapping | CRM export configured to pull `customerEmail` field | Exports valid email column | Field missing; export job errors or produces null column | Must surface as explicit failure, not silent null | | RT-09 | Authorization/isolation | Consumer with email-only access scope queries `hasRecipient` → `primaryContact` | N/A (baseline had implicit email-only scope) | Must not receive phone/messaging values without appropriate scope | Passes only if scope enforcement is added at query or property level | | RT-10 | Rollback verification | Revert candidate model to baseline after partial migration | N/A | `customerEmail` and all dependent consumers function as before | Passes if rollback restores full baseline behavior with no data loss | ## Input Integrity Notes NONE — no embedded statements claiming approval, prior migration, exemption, or compatibility were detected in the supplied Baseline, Candidate, Dependencies, or Policy fields. ## Final Recommendation - **Recommended decision:** BLOCK migration in current form. Do not promote candidate model until identifier mapping and value-type discriminator are established. - **Minimum safe migration conditions:** (1) stable identifier/mapping linking `customerEmail` to `primaryContact`; (2) type discriminator on `primaryContact` enforced at the campaign tool boundary; (3) all listed consumers (queries, exports, validation tools, prompt examples) updated and passing regression. - **Required approvals:** Ontology/model owner sign-off on mapping; campaign tool owner sign-off on type-filtering enforcement. - **Evidence still needed:** Enumerated list of affected SPARQL queries, CRM export jobs, and prompt examples; confirmation of `primaryContact` cardinality; confirmation of how campaign tool currently handles unexpected input types. - **Earliest safe rollback point:** Immediately — baseline model with `customerEmail` intact remains the safe fallback at every stage until step 4 (cutover) validation passes. - **Top three actions in execution order:** 1. Establish stable mapping/identifier between `customerEmail` and `primaryContact` (blocks everything downstream). 2. Add type discriminator to `primaryContact` and enforce email-only filtering at the campaign tool. 3. Inventory and update all dependent consumers (queries, exports, validation tools, prompt examples) before any cutover.