# USE CASE DISCOVERY PORTFOLIO ## Legacy Invoicing Repository (LIR) **Discovered by:** Stage 2 — Polysynthetic System Profiler™ **Discovery date:** April 19, 2026 **Lens set active:** full5 (operational, financial, maintenance, compliance, customer) **Depth level:** standard **Total use cases:** 23 (pre-deduplication) → 19 (post-deduplication) --- ## Section 1 — Per-Lens Raw Output ### 1.1 Operational Lens Output **Use cases identified: 5** - **UC-OPS-1**: Monthly Billing Cycle Execution - Description: The billing team triggers invoice generation on a monthly cycle, timed to run after midnight UTC. Meter reads flow in, billing calculations run, and PDF invoices are produced in batch. This is the central operational rhythm of the system. - Evidence: {from: Stage 1 §3 — Inbound: meter reads; Internal: billing calculation, invoice generation; §5 — Assumption 4: billing cycles run after midnight UTC} - Pattern type: batch - Initial tier assessment: Primary - Confidence: HIGH - Priority: HIGH - **UC-OPS-2**: Customer Account Maintenance - Description: The billing team and operations team update customer account records — residential and commercial — in response to new connections, disconnections, and account changes. Customer updates arrive as inbound data flows and are applied to the account registry. - Evidence: {from: Stage 1 §1.1 — customer account management; §3 — Inbound: customer updates} - Pattern type: workflow - Initial tier assessment: Primary - Confidence: HIGH - Priority: HIGH - **UC-OPS-3**: Meter Read Ingestion and Validation - Description: Monthly meter read records are ingested from an upstream source and processed into the system. Given that usage calculation feeds the billing cycle, this is an operational prerequisite that the operations team (8 staff) likely monitors for completeness and exceptions. - Evidence: {from: Stage 1 §1.1 — usage meter reading records, monthly cycle; §3 — Inbound: meter reads} - Pattern type: trigger - Initial tier assessment: Primary - Confidence: HIGH - Priority: HIGH - **UC-OPS-4**: Asset Registry Maintenance - Description: The system maintains a registry of poles, transformers, meters, and connection points. The operations team holds implicit responsibility for keeping this registry current, even though field service dispatch lives in a separate WFM system. Updates likely arrive via vendor catalogs or manual entry. - Evidence: {from: Stage 1 §1.1 — asset registry; §3 — Inbound: vendor catalogs} - Pattern type: workflow - Initial tier assessment: Primary - Confidence: MEDIUM - Priority: MEDIUM - **UC-OPS-5**: OMS File Drop Production - Description: The system produces outbound file drops to the Outage Management System (OMS). This is an operational output that the OMS depends on — likely customer and asset data — running on a defined schedule or trigger. The operations team (8 staff) almost certainly coordinates this handoff, even if it is automated. - Evidence: {from: Stage 1 §3 — Outbound: OMS file drops; §1.2 — OMS is a separate system} - Pattern type: batch - Initial tier assessment: Secondary - Confidence: MEDIUM - Priority: HIGH --- ### 1.2 Financial Lens Output **Use cases identified: 5** - **UC-FIN-1**: Invoice Generation and PDF Archive - Description: The system generates invoices and retains a historical archive of PDF outputs. Finance teams rely on this archive for reconciliation, dispute resolution, and period reporting. The archive implies a long-retention financial record, not just a transient billing artifact. - Evidence: {from: Stage 1 §1.1 — invoice generation with PDF output and historical archive; §3 — Internal: invoice generation} - Pattern type: batch - Initial tier assessment: Primary - Confidence: HIGH - Priority: HIGH - **UC-FIN-2**: Financial System Feed Production - Description: The LIR produces outbound feeds to a downstream financial system. This suggests the system functions as a sub-ledger or revenue source system for the utility's general ledger or ERP. The finance team (indirect stakeholder) depends on these feeds for period-close and revenue recognition. - Evidence: {from: Stage 1 §3 — Outbound: financial system feeds; §4 — Indirect: finance team} - Pattern type: batch - Initial tier assessment: Primary - Confidence: HIGH - Priority: HIGH - **UC-FIN-3**: Revenue Reconciliation Support - Description: Finance teams likely use the invoice archive and financial feeds together to reconcile billed revenue against collected amounts. The system holds the billing-side record; the downstream financial system holds the receipt-side. The LIR is the authoritative source for what was billed. - Evidence: {from: Stage 1 §1.1 — historical archive; §3 — Outbound: financial system feeds; §4 — Indirect: finance team} - Pattern type: workflow - Initial tier assessment: Secondary - Confidence: MEDIUM - Priority: HIGH - **UC-FIN-4**: Vendor Catalog-Driven Cost Data Ingestion - Description: Vendor catalogs arrive as inbound data flows. In an energy-utilities context, this likely includes pricing for materials, connection fees, or asset-related charges that feed into billing calculations. This is a Secondary use — the system was not designed as a procurement tool, but vendor data flows through it. - Evidence: {from: Stage 1 §3 — Inbound: vendor catalogs} - Pattern type: trigger - Initial tier assessment: Secondary - Confidence: MEDIUM - Priority: MEDIUM - **UC-FIN-5**: Invoice Dispute Evidence Retrieval - Description: When customers dispute charges, the billing team and finance team retrieve archived PDF invoices and underlying usage records to substantiate or correct the bill. The historical archive is the primary evidence source for dispute resolution. - Evidence: {from: Stage 1 §1.1 — historical archive; §4 — Direct users: billing team} - Pattern type: workflow - Initial tier assessment: Secondary - Confidence: HIGH - Priority: MEDIUM --- ### 1.3 Maintenance Lens Output **Use cases identified: 5** - **UC-MNT-1**: Maintenance Log as De Facto Asset History - Description: A maintenance_log table exists with 7 years of entries, not mentioned in the system's own documentation. This table is almost certainly the operational record of what happened to which assets over time. Given the defunct WFM system, the LIR may now be the only surviving copy of this maintenance history. - Evidence: {from: Stage 1 §2.3 — maintenance_log table exists with 7 years of entries, not in description; §5 — Assumption 3: maintenance_log kept in sync with external WFM system (now defunct)} - Pattern type: other (undocumented record) - Initial tier assessment: Secondary - Confidence: HIGH - Priority: HIGH - **UC-MNT-2**: Asset-to-Address Spatial Linkage for Field Operations - Description: The undocumented addresses.pole_id FK links the address registry to the asset registry at the pole level, with geocoded coordinates on each address. Operations teams likely use this linkage to locate assets geographically — a maintenance planning use the system was not formally designed to support. - Evidence: {from: Stage 1 §2.3 — addresses.pole_id FK is undocumented but present; §1.1 — address registry with geocoded coordinates; asset registry — poles, transformers, meters} - Pattern type: workflow - Initial tier assessment: Secondary - Confidence: MEDIUM - Priority: HIGH - **UC-MNT-3**: Pole ID Stability Assumption as Maintenance Risk - Description: The system assumes pole IDs are stable over time with no pole_id history table. When poles are replaced or renumbered, historical asset linkages become orphaned. This is not an active use case — it is a gap that maintenance teams likely work around manually, or that silently corrupts asset-to-address relationships over time. - Evidence: {from: Stage 1 §5 — Assumption 2: Pole IDs stable over time, no pole_id history table} - Pattern type: other (gap/risk) - Initial tier assessment: Outlier - Confidence: MEDIUM - Priority: HIGH - **UC-MNT-4**: Defunct WFM Sync as Orphaned Dependency - Description: The maintenance_log was assumed to stay in sync with the external WFM system, which is now defunct. The LIR likely stopped receiving WFM updates at some point. The maintenance_log may therefore contain a 7-year record with a silent staleness boundary — an unknown date after which entries may be incomplete. - Evidence: {from: Stage 1 §5 — Assumption 3: maintenance_log kept in sync with WFM (now defunct); §2.3 — maintenance_log exists with 7 years of entries} - Pattern type: other (orphaned dependency) - Initial tier assessment: Outlier - Confidence: MEDIUM - Priority: HIGH - **UC-MNT-5**: Customer-to-Asset Linkage for Connection Point Tracking - Description: The customer-to-asset linkage in the LIR connects customer accounts to specific connection points (and by extension, to meters, transformers, and poles). Operations teams likely use this to identify which customers are affected when a specific asset fails or requires maintenance — a use not part of the billing design intent. - Evidence: {from: Stage 1 §1.1 — customer-to-asset linkage, connection points} - Pattern type: workflow - Initial tier assessment: Secondary - Confidence: MEDIUM - Priority: MEDIUM --- ### 1.4 Compliance Lens Output **Use cases identified: 4** - **UC-CMP-1**: Audit Log Production and Retention - Description: The LIR performs internal audit logging as part of its data flow. In an energy-utilities context, this log is likely subject to regulatory retention requirements (NERC CIP, state PUC mandates, or both). The compliance audit team (indirect stakeholder) depends on this log for periodic audit submissions and incident investigation. - Evidence: {from: Stage 1 §3 — Internal: audit logging; §4 — Indirect: compliance audit team} - Pattern type: real-time - Initial tier assessment: Primary - Confidence: HIGH - Priority: HIGH - **UC-CMP-2**: Invoice Archive as Regulatory Evidence - Description: Energy utilities in most jurisdictions must retain billing records for defined periods (typically 5-7 years under state PUC rules). The LIR's historical PDF archive serves this retention requirement. The archive is not merely a financial tool — it is a compliance artifact that auditors can demand on short notice. - Evidence: {from: Stage 1 §1.1 — historical archive; §4 — Indirect: compliance audit team} - Pattern type: other (retention) - Initial tier assessment: Primary - Confidence: HIGH - Priority: HIGH - **UC-CMP-3**: Schema Staleness as Compliance Exposure - Description: The schema dump is 14 months old and marked for verification. If the LIR's data structures have changed since the dump was taken — new tables, altered audit columns — the compliance team may be operating on a false picture of what the system retains. This is an Outlier: it is not a use case the system runs, but a compliance risk created by documentation lag. - Evidence: {from: Stage 1 §6 — Schema dump is 14 months old [verify current]} - Pattern type: other (compliance risk) - Initial tier assessment: Outlier - Confidence: MEDIUM - Priority: HIGH - **UC-CMP-4**: Geocoded Address Data as Data Sovereignty Asset - Description: The address registry includes geocoded coordinates. In several jurisdictions, customer location data with precision coordinates carries data classification and handling requirements beyond basic customer PII. The compliance team may not have assessed this, as geocoding is often treated as an operational feature rather than a data governance concern. - Evidence: {from: Stage 1 §1.1 — address registry with geocoded coordinates; §5 — Assumption 1: addresses geocoded upstream} - Pattern type: other (data classification) - Initial tier assessment: Outlier - Confidence: LOW - Priority: MEDIUM --- ### 1.5 Customer Lens Output **Use cases identified: 4** - **UC-CUS-1**: PDF Invoice Delivery as Customer-Facing Output - Description: The primary customer-facing output of the LIR is the generated PDF invoice. Customers — residential and commercial — receive these invoices and act on them. Accuracy, timeliness, and format correctness are all SLA-relevant from a customer perspective. Late or malformed invoices create downstream complaints that feed back into the billing team. - Evidence: {from: Stage 1 §1.1 — invoice generation with PDF output; §3 — Outbound: PDF invoices; §4 — Direct users: billing team} - Pattern type: batch - Initial tier assessment: Primary - Confidence: HIGH - Priority: HIGH - **UC-CUS-2**: OMS Data Feed as Indirect Customer Experience Driver - Description: The OMS file drop from the LIR carries customer and asset data to the Outage Management System. When that data is stale or malformed, outage crews may lack accurate customer counts, contact information, or affected-asset mappings. Customers experience the downstream quality of this feed during outage events, even though they never interact with the LIR directly. - Evidence: {from: Stage 1 §3 — Outbound: OMS file drops; §1.2 — OMS is a separate system} - Pattern type: batch - Initial tier assessment: Secondary - Confidence: MEDIUM - Priority: HIGH - **UC-CUS-3**: Commercial Customer Account Complexity - Description: The LIR manages both residential and commercial accounts. Commercial accounts in energy utilities typically carry more complex billing structures — demand charges, time-of-use rates, multi-site accounts. The billing team's workload on commercial accounts is likely disproportionate to their count, and the system may hold commercial-specific data structures not visible in the high-level profile. - Evidence: {from: Stage 1 §1.1 — customer account management (residential + commercial)} - Pattern type: workflow - Initial tier assessment: Outlier - Confidence: LOW - Priority: MEDIUM - **UC-CUS-4**: Invoice Archive Access for Customer Dispute and History - Description: Customers (or their representatives) who dispute charges or request billing history trigger a retrieval workflow in the billing team. The PDF archive is the customer-facing evidence source in these interactions. Response time and archive completeness directly affect customer experience quality. - Evidence: {from: Stage 1 §1.1 — historical archive; §4 — Direct users: billing team (15)} - Pattern type: workflow - Initial tier assessment: Secondary - Confidence: HIGH - Priority: MEDIUM --- ## Section 2 — Deduplication and Conflict Resolution ### 2.1 Merged Use Cases - **Merged UC-INV-ARC**: Invoice Archive — Financial, Compliance, and Customer Use - Merged from: UC-FIN-1 (partial), UC-FIN-5, UC-CMP-2, UC-CUS-4 - Consolidated evidence: §1.1 — historical archive; §3 — Internal: invoice generation; §4 — billing team, compliance audit team, finance team - Why merged: All four lenses independently identified the PDF archive as a distinct use case. They approached it from different angles (revenue reconciliation, regulatory retention, dispute resolution), but the underlying system behavior — retaining and serving archived PDFs — is a single use case with multiple consumer classes. Preserving the four-lens perspective as evidence of breadth, while treating it as one use case for the portfolio. - **Merged UC-OMS-FEED**: OMS File Drop as Operational and Customer-Affecting Output - Merged from: UC-OPS-5, UC-CUS-2 - Consolidated evidence: §3 — Outbound: OMS file drops; §1.2 — OMS separate system - Why merged: The Operational Lens identified this as an operational output; the Customer Lens identified it as an indirect customer experience driver. Same system behavior, two consumer perspectives. Merged with both angles preserved in description. - **Merged UC-MNT-LOG**: Maintenance Log as Undocumented Operational Record - Merged from: UC-MNT-1, UC-MNT-4 - Consolidated evidence: §2.3 — maintenance_log, 7 years of entries; §5 — Assumption 3: WFM sync now defunct - Why merged: UC-MNT-1 identified the log as a de facto asset history; UC-MNT-4 identified the orphaned WFM dependency as a staleness risk within that same log. These are two facets of one use case and one risk. Merged with both the active-use and risk dimensions in the description. ### 2.2 Tier Disagreements Resolved - UC-FIN-1 / UC-INV-ARC (archive): - Financial Lens said: Primary (designed invoice output) - Compliance Lens said: Primary (retention requirement) - Customer Lens said: Secondary (dispute retrieval is adjacent to billing design) - Resolution: **Primary** — The archive is explicitly part of the system's described functionality (§1.1). The secondary uses (compliance retention, dispute resolution) are material but do not change the tier of the underlying capability. - UC-OPS-5 / UC-OMS-FEED: - Operational Lens said: Secondary (OMS is a separate system; file drop is adjacent) - Customer Lens said: Secondary - Resolution: **Secondary** — Both lenses agree. The LIR was not designed as an OMS feeder; this is an adapted use. ### 2.3 Priority Disagreements Resolved - UC-MNT-3 (Pole ID stability gap): - Maintenance Lens flagged: HIGH priority (silent data corruption risk) - No counter-lens disagreement, but priority HIGH is retained given migration risk: if pole IDs have changed in the 14-month schema gap, asset-to-address linkages in a migrated system would be corrupted on day one. --- ## Section 3 — PRIMARY Use Cases *What the system was designed for* --- - **UC-P-01**: Monthly Billing Cycle Execution - **Description:** The LIR's core operational function. Monthly meter reads trigger billing calculations that produce PDF invoices for residential and commercial customers. The cycle runs after midnight UTC. The billing team (15 staff) owns this workflow. Failure in this cycle is the highest-severity operational event the system can produce. - **Evidence:** §1.1 — meter reading records, invoice generation; §3 — Inbound: meter reads; Internal: billing calculation, invoice generation; §5 — Assumption 4 - **Lens(es) that surfaced it:** Operational, Financial - **Confidence:** HIGH - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-P-02**: Customer Account Management - **Description:** The billing team maintains the residential and commercial account registry as a continuous workflow — new connections, disconnections, rate changes, and contact updates. Inbound customer updates drive this workflow. The account registry is the master entity that anchors invoices, meter reads, and asset linkages. - **Evidence:** §1.1 — customer account management; §3 — Inbound: customer updates - **Lens(es) that surfaced it:** Operational - **Confidence:** HIGH - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-P-03**: Meter Read Ingestion and Validation - **Description:** Monthly meter reads arrive as inbound data and must be ingested, validated, and associated with the correct customer accounts before billing can run. The operations team monitors this flow for completeness and exception handling. A failed meter read ingestion directly blocks the billing cycle. - **Evidence:** §1.1 — meter reading records; §3 — Inbound: meter reads - **Lens(es) that surfaced it:** Operational - **Confidence:** HIGH - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-P-04**: Invoice Archive — Financial, Compliance, and Customer Use *(Merged UC-INV-ARC)* - **Description:** The LIR retains a historical archive of generated PDF invoices. This archive serves at minimum three distinct consumer classes: (1) the finance team uses it for revenue reconciliation and period reporting; (2) the compliance audit team uses it to satisfy regulatory retention requirements under state PUC billing record mandates (typically 5-7 years); and (3) the billing team retrieves specific invoices to resolve customer disputes. The archive is a single system capability with high-value use across all three. - **Evidence:** §1.1 — invoice generation with PDF output and historical archive; §3 — Outbound: financial system feeds; §4 — billing team, compliance audit team, finance team - **Lens(es) that surfaced it:** Financial, Compliance, Customer - **Confidence:** HIGH - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-P-05**: Financial System Feed Production - **Description:** The LIR produces outbound data feeds to the downstream financial system, effectively functioning as the billing sub-ledger for the utility's general ledger or ERP. The finance team depends on these feeds for period-close and revenue recognition. Feed timing, completeness, and format are all critical to downstream financial operations. - **Evidence:** §3 — Outbound: financial system feeds; §4 — Indirect: finance team - **Lens(es) that surfaced it:** Financial - **Confidence:** HIGH - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-P-06**: Audit Log Production - **Description:** The LIR performs continuous internal audit logging. In an energy-utilities regulatory context, this log supports compliance audit team reviews, incident investigations, and potential regulator demands. The log is likely subject to a defined retention period and must be tamper-evident to carry evidentiary weight. - **Evidence:** §3 — Internal: audit logging; §4 — Indirect: compliance audit team - **Lens(es) that surfaced it:** Compliance - **Confidence:** HIGH - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-P-07**: Asset Registry Maintenance - **Description:** The operations team maintains the registry of poles, transformers, meters, and connection points. Vendor catalogs are the likely inbound data source for asset additions and updates. This registry anchors both the customer-to-asset linkage and the undocumented pole_id FK — making it structurally load-bearing for several Secondary use cases. - **Evidence:** §1.1 — asset registry; §3 — Inbound: vendor catalogs - **Lens(es) that surfaced it:** Operational - **Confidence:** MEDIUM - **Priority:** MEDIUM - **Preservation-critical?:** Yes --- ## Section 4 — SECONDARY Use Cases *Adjacent patterns actively in use but not part of original design* --- - **UC-S-01**: OMS File Drop — Operational Handoff and Customer Impact Driver *(Merged UC-OMS-FEED)* - **Description:** The LIR produces outbound file drops to the Outage Management System. This is not a designed billing output — it is an adapted data-sharing arrangement between two separate systems. The OMS depends on this feed for customer account data and asset linkages used during outage response. When the feed is stale or malformed, outage crews work with degraded customer data, and affected customers experience longer or less-targeted restoration. The operations team coordinates this handoff, likely manually or via scheduled job. - **Evidence:** §1.1 — customer-to-asset linkage; §3 — Outbound: OMS file drops; §1.2 — OMS is a separate system - **Lens(es) that surfaced it:** Operational, Customer - **Confidence:** MEDIUM - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-S-02**: Maintenance Log as De Facto Asset History *(Merged UC-MNT-LOG)* - **Description:** A maintenance_log table with 7 years of entries exists in the schema but is absent from the system's documentation. Given that the WFM system it synced with is now defunct, the LIR may be the only surviving system holding this maintenance history. Operations teams and potentially the compliance team likely access this log — whether through direct queries, reports, or informal extraction — to reconstruct asset histories, investigate incidents, or support insurance or regulatory claims. The log almost certainly has a staleness boundary at the point the WFM sync stopped; that boundary date is currently unknown and must be established before the log can be used with confidence. - **Evidence:** §2.3 — maintenance_log table, 7 years of entries, not in description; §5 — Assumption 3: WFM sync defunct - **Lens(es) that surfaced it:** Maintenance - **Confidence:** HIGH - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-S-03**: Asset-to-Address Spatial Linkage for Field Operations - **Description:** The undocumented addresses.pole_id FK creates a navigable link from customer addresses (with geocoded coordinates) to physical asset locations. Operations teams likely use this linkage to answer spatial questions: which customers connect to a specific pole or transformer, and where is that asset on the ground. This is a field-planning use that the billing system was not designed to support, but actively enables through its combined data model. - **Evidence:** §2.3 — addresses.pole_id FK undocumented; §1.1 — address registry with geocoded coordinates, customer-to-asset linkage - **Lens(es) that surfaced it:** Maintenance, Operational - **Confidence:** MEDIUM - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-S-04**: Revenue Reconciliation Support - **Description:** Finance teams use the invoice archive and financial system feeds together to reconcile what the LIR billed against what the financial system recorded as received. The LIR is the authoritative billing-side record; the downstream financial system holds the receipt-side. This reconciliation workflow depends on consistent invoice IDs, period markers, and amount fields surviving the handoff through the financial feed. - **Evidence:** §1.1 — historical archive; §3 — Outbound: financial system feeds; §4 — Indirect: finance team - **Lens(es) that surfaced it:** Financial - **Confidence:** MEDIUM - **Priority:** HIGH - **Preservation-critical?:** Yes --- - **UC-S-05**: Vendor Catalog-Driven Cost Data Ingestion - **Description:** Vendor catalogs arrive as inbound data to the LIR. In an energy-utilities context, this likely carries material and service pricing that feeds into connection fees, asset-related charges, or rate adjustments applied at billing time. The system was designed as a billing engine, not a procurement system, but it ingests and acts on vendor pricing data — making it a Secondary participant in the cost management process. - **Evidence:** §3 — Inbound: vendor catalogs; §6 — Vendor defunct status [reconfirm] - **Lens(es) that surfaced it:** Financial - **Confidence:** MEDIUM - **Priority:** MEDIUM - **Preservation-critical?:** No --- - **UC-S-06**: Customer-to-Asset Linkage for Outage Impact Assessment - **Description:** The customer-to-asset linkage records which customers connect to which physical assets (meters, connection points, transformers). Operations teams likely query this linkage to determine how many customers — and which ones — a given asset's failure would affect. This is a Secondary use: the linkage exists for billing purposes, but it doubles as a service-impact assessment tool, particularly given the defunct WFM system that may have previously served this need. - **Evidence:** §1.1 — customer-to-asset linkage, connection points; §5 — Assumption 3: WFM defunct - **Lens(es) that surfaced it:** Maintenance, Customer - **Confidence:** MEDIUM - **Priority:** MEDIUM - **Preservation-critical?:** Yes --- ## Section 5 — OUTLIER Use Cases *Edge cases, workarounds, extension opportunities* --- - **UC-O-01**: Pole ID Stability Gap — Silent Asset Linkage Corruption - **Description:** The system holds no pole_id history table, operating on the assumption that pole IDs never change. When a pole is replaced or renumbered, any address or customer record linked to the old pole_id becomes silently orphaned. Operations teams likely have manual workarounds — spreadsheets, informal notes — to track pole replacements that the system cannot record. This is not an active use case; it is a structural gap that generates hidden data quality debt, with highest impact in migration scenarios where the LIR's asset linkages would be carried forward into a new system. - **Evidence:** §5 — Assumption 2: Pole IDs stable over time, no pole_id history table; §2.3 — addresses.pole_id FK undocumented - **Lens(es) that surfaced it:** Maintenance - **Confidence:** MEDIUM - **Priority:** HIGH - **Preservation-critical?:** No (gap, not a capability — but must be documented before migration) --- - **UC-O-02**: Schema Staleness as Compliance and Migration Exposure - **Description:** The schema dump is 14 months old. If the LIR's live schema has diverged from the dump — new tables, dropped columns, altered audit fields — then every use case built on schema evidence carries unquantified error. For compliance, this means the audit log's current structure is unknown. For migration, it means the data model being migrated may not reflect what is actually in production. This is an Outlier that creates risk across Primary, Secondary, and other Outlier use cases simultaneously. - **Evidence:** §6 — Schema dump is 14 months old [verify current]; §3 — Internal: audit logging - **Lens(es) that surfaced it:** Compliance - **Confidence:** MEDIUM - **Priority:** HIGH - **Preservation-critical?:** No (risk item — blocks confident preservation of others) --- - **UC-O-03**: Geocoded Address Data as Unassessed Data Governance Asset - **Description:** The address registry holds geocoded coordinates for customer addresses. In an energy-utilities context, precision customer location data may carry data classification obligations under state privacy regulations or federal infrastructure security frameworks (e.g., customer location data for critical infrastructure customers). This has not been surfaced as a known concern in the Stage 1 profile, which suggests it has not been assessed. The risk is low-probability but potentially material if a regulatory review surfaces it during or after migration. - **Evidence:** §1.1 — address registry with geocoded coordinates; §5 — Assumption 1: geocoding performed upstream - **Lens(es) that surfaced it:** Compliance - **Confidence:** LOW - **Priority:** MEDIUM - **Preservation-critical?:** No --- - **UC-O-04**: Commercial Account Billing Complexity as Hidden Scope - **Description:** The LIR manages both residential and commercial accounts under a single account management model. Commercial utility billing in the energy sector routinely involves demand charges, time-of-use rates, multi-premise accounts, and contract-driven rate schedules that differ materially from residential billing. The Stage 1 profile makes no distinction between the two account types in terms of data structures or billing logic. If the system handles commercial complexity, that logic is invisible in the current profile and could represent significant undocumented scope — particularly in a migration. - **Evidence:** §1.1 — customer account management (residential + commercial) - **Lens(es) that surfaced it:** Customer - **Confidence:** LOW - **Priority:** MEDIUM - **Preservation-critical?:** No (requires stakeholder validation to determine scope) --- ## Section 6 — Coverage Self-Assessment ### 6.1 Lens Coverage Matrix | | Primary | Secondary | Outlier | Total | |-------------|---------|-----------|---------|-------| | Operational | 4 | 1 | 0 | 5 | | Financial | 3 | 2 | 0 | 5 | | Maintenance | 0 | 3 | 2 | 5 | | Compliance | 2 | 0 | 2 | 4 | | Customer | 1 | 2 | 1 | 4 | | **Total** | **10** | **8** | **5** | **23**| *(Pre-deduplication counts. Post-dedup portfolio: 7 Primary, 6 Secondary, 4 Outlier = 19 total.)* ### 6.2 Lens Contribution Notes **Maintenance Lens** was the most differentiating lens in this engagement. It surfaced UC-S-02 (the undocumented maintenance_log with 7 years of entries) and UC-S-03 (the undocumented pole_id FK spatial linkage) — both high-priority Secondary use cases that are invisible to the other four lenses and would be the most likely to be lost in a migration. Zero Primary use cases from the Maintenance Lens is expected and correct: the LIR was not designed as a maintenance system, but it has been quietly adapted to carry maintenance data. **Operational and Financial Lenses** produced predominantly Primary use cases, as expected. The system's designed purpose is billing, and both lenses read that clearly. Financial Lens added meaningful Secondary use cases (revenue reconciliation, vendor cost ingestion) that sit just outside the billing design intent. **Compliance Lens** produced zero Secondary use cases. This is a mild signal: in an energy-utilities context, one would expect at least one Secondary compliance use (e.g., the audit log being used for regulatory reporting beyond its designed scope). This may indicate that the Stage 1 profile did not surface compliance-adjacent adaptation, or that the compliance team's actual usage patterns are not visible in the available profile data. Recommend a focused stakeholder interview with the compliance audit team before Stage 3. **Customer Lens** contributed meaningfully through its identification of the OMS file drop's customer impact (UC-S-01) and the commercial account complexity gap (UC-O-04). Both findings required reasoning beyond the Stage 1 profile's explicit content, which accounts for the MEDIUM/LOW confidence ratings on those items. ### 6.3 Soft Scope Creep Check Items rated Confidence: LOW — rationale for Stage 3 scope gate: - **UC-O-03** (Geocoded address data governance): Confidence is LOW because the Stage 1 profile does not indicate that this has ever been assessed as a data classification concern. The risk exists in principle but has no evidence of materiality in this system. Stage 3 should flag this as a stakeholder question, not a confirmed use case. - **UC-O-04** (Commercial account billing complexity): Confidence is LOW because the Stage 1 profile treats residential and commercial accounts as a single entity class with no differentiation. The complexity hypothesis is grounded in domain knowledge of energy-utilities billing, not in evidence from the profile. Stage 3 must not treat this as confirmed scope; it must be validated with the billing team before any migration design decisions depend on it. Both LOW-confidence items are Outliers. Neither appears in the Primary or Secondary tiers, which limits their risk to Stage 3. However, both carry non-trivial priority (MEDIUM) and must not silently disappear from the portfolio. --- ## Section 7 — Handoff to Stage 3 - **Total Primary count:** 7 - **Total Secondary count:** 6 - **Total Outlier count:** 4 (including 2 risk/gap items, not active capabilities) - **Preservation-critical count:** 10 (all 7 Primary + UC-S-01, UC-S-02, UC-S-03, UC-S-06) - **Low-confidence items requiring stakeholder validation:** 2 (UC-O-03, UC-O-04) **Stage 3 routing recommendation:** Secondary (6) and Primary (7) are nearly equal in count, but the Secondary use cases carry disproportionate preservation risk: UC-S-02 (maintenance_log), UC-S-03 (spatial linkage), and UC-S-01 (OMS feed) are all HIGH priority and would be the first casualties of a migration that only surveyed the designed system. **Migration mode is the primary Stage 3 mode for this engagement.** Additionally, UC-O-01 (pole ID staleness) and UC-O-02 (schema staleness) are HIGH-priority Outliers that function as data quality gates — they do not represent capabilities to migrate, but they must be resolved before migration design can proceed with confidence. A **dual-pass is recommended**: the first pass addresses the two schema/data-quality Outliers as pre-migration remediation items; the second pass runs full migration synthesis on the confirmed use case portfolio. The two LOW-confidence Outliers (UC-O-03, UC-O-04) require stakeholder validation sessions with the compliance audit team and the billing team respectively before Stage 3 synthesis should include them. --- *Stage 2 — Use Case Discovery Engine v1.0* *Framework: MONNA SIGNATURE™ v10.2 | Polysynthetic Lensing* *Input: LIR System Utilization Profile | Output: Stage 3 input portfolio*