# SYSTEM UTILIZATION PROFILE ## Legacy Invoicing Repository (LIR) **Profiled by:** Stage 1 — Polysynthetic System Profiler™ **Profile date:** 2026-04-19 **Retrieval strategy:** Schema-aware **Depth level:** Standard **Domain:** Energy-utilities --- ## Section 1 — System Boundaries ### 1.1 What the System Contains - **Consumption-based billing** — calculates invoice amounts from meter readings for residential and commercial customers. {Source: system description} - **Monthly invoice generation with PDF output** — produces invoices on a billing-period cycle and exports them as PDF. {Source: system description} - **Customer account management** — stores customer records linked to service addresses and account type (residential vs. commercial). {Source: schema — `customers`, `addresses`} - **Meter reading storage** — retains timestamped kWh readings per meter. {Source: schema — `meter_readings`} - **Asset-to-customer linkage** — associates physical assets with customer accounts over time via `start_date`/`end_date`. {Source: schema — `customer_assets`} - **Address-to-pole linkage** — addresses carry a `pole_id` FK, enabling traversal from service address to infrastructure asset. {Source: schema — `addresses.pole_id`} - **Maintenance logging** — records scheduled maintenance events, including cascaded affected asset IDs. {Source: schema — `maintenance_log`; flagged as out-of-original-spec} - **Access auditing** — logs user actions with timestamps via `controlled_access_log`. {Source: schema} - **Ad-hoc pole-tracing workflow** — operations staff trace pole locations by address to identify affected asset IDs and billing accounts during scheduled pole maintenance. {Source: system description} ### 1.2 What the System Excludes - **Payment processing** — no tables for payments, receipts, or payment gateway integration are present. {Source: schema — absence} - **Real-time meter data ingestion** — `meter_readings` stores values but the system description names no live feed mechanism or meter-communication protocol. {Source: system description — absence; schema — absence} - **Customer-facing self-service** — no user interface layer or web portal is described or implied. {Source: system description — absence} - **Field crew scheduling or dispatch** — maintenance events are logged, but no workflow, crew assignment, or scheduling capability is present in the schema or description. {Source: schema — absence} - **Network topology modeling** — the system does not model pole-to-pole or pole-to-feeder relationships; `pole_id` is a flat FK on `addresses`, not a graph structure. {Source: schema} - **Outage management** — no outage, fault, or interruption entities exist. {Source: schema — absence} - **Regulatory reporting outputs** — no dedicated reporting entities, export formats, or compliance-specific fields are documented. {Source: schema — absence; system description — absence} ### 1.3 Integration Boundaries | Direction | Counterpart | Data Exchanged | Source of Knowledge | |---|---|---|---| | Receives from (inferred) | Meter reading collection system | `kwh_value`, `meter_id`, `read_date` | {INFERRED from: `meter_readings` schema — values must originate somewhere} | | Receives from (inferred) | Address/geocoding source | `lat`, `lon`, `pole_id` on `addresses` | {INFERRED from: schema — LIR stores geocoded data but no input process is documented} | | Received from (defunct) | WFM vendor system | Maintenance scheduling records | {Source: `maintenance_log.source_system = 'WFM-vendor-defunct'`} | | Outbound (stated) | PDF rendering/delivery layer | Monthly invoice PDFs | {Source: system description — "PDF output"; mechanism not documented} | | Unknown | Any current maintenance scheduling system | Unknown — WFM vendor is defunct | {INFERRED from: schema — `source_system` value suggests replacement may or may not exist} | --- ## Section 2 — Entities and Relationships ### 2.1 Core Entities **customers** - Purpose: Represents a billing account holder (residential or commercial). - Key attributes: `customer_id`, `name`, `account_type`, `service_address_id` - Lifecycle: Created at account opening; `account_type` distinguishes billing tier. No archival or closure field present. {INFERRED from: schema — absence of status/closure field is a gap} - Source: Schema **addresses** - Purpose: Physical service locations; also serves as a spatial anchor for infrastructure assets. - Key attributes: `address_id`, `street`, `city`, `zip`, `lat`, `lon`, `pole_id` - Lifecycle: Created when a customer or asset is registered to a location. No update/decommission mechanism documented. - Source: Schema; `pole_id` undocumented {Source: schema notes} **assets** - Purpose: Physical infrastructure items (type unspecified — meters, poles, transformers, etc.). - Key attributes: `asset_id`, `asset_type`, `location_address_id`, `installed_date` - Lifecycle: Created at installation (`installed_date`). No decommission or retirement field. {INFERRED from: schema — absence of end-of-life field} - Source: Schema **meter_readings** - Purpose: Time-series record of energy consumption per meter. - Key attributes: `reading_id`, `meter_id`, `read_date`, `kwh_value` - Lifecycle: Created on each read cycle. No deletion or correction mechanism documented. {INFERRED from: schema} - Note: `meter_id` FK target table is not present in the schema. {TEMPORAL: verify currency as of 2026-04-19 — `meter_id` may reference a missing or external table} - Source: Schema **invoices** - Purpose: Billing record for a customer covering a defined period. - Key attributes: `invoice_id`, `customer_id`, `billing_period`, `total_amount`, `status` - Lifecycle: Generated monthly; `status` implies a workflow (draft → issued → paid/overdue?) but valid status values are not documented. - Source: Schema **invoice_line_items** - Purpose: Itemized breakdown of charges within an invoice. - Key attributes: `line_id`, `invoice_id`, `description`, `amount` - Lifecycle: Created alongside parent invoice. No amendment mechanism documented. - Source: Schema **customer_assets** - Purpose: Junction entity associating customers with assets over time (e.g., meter assignment). - Key attributes: `customer_id`, `asset_id`, `start_date`, `end_date` - Lifecycle: `end_date` NULL implies active assignment. No PK is defined — composite key assumed. {INFERRED from: schema} - Source: Schema **maintenance_log** - Purpose: Records scheduled maintenance events and the asset IDs they affect. Used operationally for pole-tracing workflows. - Key attributes: `log_id`, `asset_id`, `scheduled_date`, `affected_asset_ids[]` (array), `source_system`, `created_at` - Lifecycle: Created when maintenance is scheduled. `source_system = 'WFM-vendor-defunct'` indicates historical records came from a now-defunct vendor feed. Current population mechanism is unknown. - Source: Schema; explicitly flagged as not in original specification {Source: schema notes} **controlled_access_log** - Purpose: Audit trail of user actions within the system. - Key attributes: `access_id`, `user_id`, `action`, `timestamp` - Lifecycle: Append-only (assumed). Retention policy not documented. - Source: Schema ### 2.2 Explicit Relationships | Entity A | Relationship | Entity B | Cardinality | Source | |---|---|---|---|---| | customers | has one | addresses (service) | N:1 | Schema FK | | addresses | optionally references | assets (via `pole_id`) | N:1 | Schema FK (undocumented) | | assets | located at | addresses | N:1 | Schema FK | | meter_readings | recorded for | meters (implied) | N:1 | Schema FK — target missing | | invoices | issued to | customers | N:1 | Schema FK | | invoice_line_items | belongs to | invoices | N:1 | Schema FK | | customer_assets | links | customers ↔ assets | M:N | Schema junction | | maintenance_log | references primary | assets | N:1 | Schema FK | | maintenance_log | references cascaded | assets (array) | 1:N (array) | Schema — `affected_asset_ids[]` | ### 2.3 Inferred Relationships - **meters → assets**: `meter_readings.meter_id` almost certainly references a meter, which is an `asset_type` in the `assets` table — but no FK constraint ties them. {INFERRED from: schema structure} — Stakeholder validation required. - **maintenance_log → addresses**: Operational pole-tracing traverses `maintenance_log → assets → addresses → pole_id`. This join path is operationally depended upon but is nowhere documented as an intended query pattern. {INFERRED from: system description + schema} - **customers → affected maintenance**: The operations workflow implies a join path from `maintenance_log.affected_asset_ids[]` → `customer_assets` → `customers` to identify billing accounts at risk. This path uses an array column, suggesting either application-side unnesting or a non-standard join. {INFERRED from: system description + schema} --- ## Section 3 — Data Flows ### 3.1 Inbound Flows | Source | Data | Format/Volume | Trigger | Destination Entity | |---|---|---|---|---| | Meter collection system (inferred) | kWh readings per meter | Unknown format; monthly minimum | Scheduled or manual | `meter_readings` | | Operations staff (manual, inferred) | Maintenance schedules | Unknown; previously via WFM feed | Ad-hoc or scheduled | `maintenance_log` | | Address/geocoding source (inferred) | `lat`, `lon`, `pole_id` | Unknown | At address creation | `addresses` | | Operators (manual) | Ad-hoc pole-tracing queries | Interactive | Event-driven (maintenance scheduling) | Read-only traversal | ### 3.2 Internal Flows - **Meter readings → Invoice generation**: `meter_readings.kwh_value` values for a billing period aggregate into a consumption figure; this drives `invoice_line_items.amount` and rolls up to `invoices.total_amount`. Transformation logic is not documented — presumably application code. {INFERRED from: system description + schema} - **customer_assets → Invoice scoping**: The system must resolve which asset (meter) belongs to which customer during billing. `customer_assets` provides this, using `start_date`/`end_date` to handle reassignments. {INFERRED from: schema} - **addresses + pole_id → maintenance impact tracing**: Operators join `addresses.pole_id` against `assets` and `maintenance_log` to identify affected customers. This is an internal read path with no write output documented. ### 3.3 Outbound Flows | Destination | Data | Format | Trigger | Source Entity | |---|---|---|---|---| | Customer / delivery mechanism | Monthly invoice | PDF | Billing cycle completion | `invoices`, `invoice_line_items` | | Operations team | Pole-trace results (affected accounts) | Unknown — screen output assumed | Ad-hoc query | `maintenance_log`, `assets`, `addresses`, `customers` | | Audit/compliance consumers (inferred) | Access log records | Unknown | On-demand or periodic | `controlled_access_log` | --- ## Section 4 — Stakeholder Map ### 4.1 Direct Users | Role | Actions Performed | Frequency | Source | |---|---|---|---| | Billing operators | Generate invoices, review line items, manage billing cycle | Monthly | System description | | Operations team | Trace pole locations to identify affected assets and billing accounts | Ad-hoc, event-driven | System description | | System administrators (inferred) | Control access, manage user accounts | Periodic | {INFERRED from: `controlled_access_log`} | ### 4.2 Indirect Stakeholders - **Residential and commercial customers** — receive invoice PDFs; do not interact with the system directly. {Source: system description} - **Audit / compliance teams** — likely consumers of `controlled_access_log` data, given energy-utility regulatory environments typically require access auditing. {INFERRED from: domain + schema} - **Field maintenance crews** — act on the output of the operations team's pole-tracing queries but do not interact with LIR directly. {INFERRED from: system description} - **Finance / accounts receivable** — depend on invoice data for revenue tracking; no direct interface documented. {INFERRED from: domain} ### 4.3 System Owners / Operators - **Original developer** — departed 4 years ago. No handover documentation referenced. {Source: system description} - **Current maintainer** — not identified. This is a critical gap: no named owner, incident responder, or access-control authority is documented. {INFERRED from: system description — absence} - **Vendor** — defunct since 2022. No support relationship exists. {Source: system description} - {TEMPORAL: verify currency as of 2026-04-19 — confirm whether any internal team member has assumed de-facto ownership and whether that is formally recorded} --- ## Section 5 — Implicit Assumption Inventory **Assumption 1: `pole_id` values in `addresses` are accurate and maintained** - Evidence: `addresses.pole_id` is an undocumented FK with no stated maintenance process. The system description says operations staff rely on address-to-pole tracing for maintenance planning. - Risk if violated: Operations team identifies wrong poles or misses affected accounts, potentially leaving customers without warning before service interruption. - Validation target: Operations team lead; whoever last updated address records. **Assumption 2: `maintenance_log` is still being populated by some process** - Evidence: `source_system = 'WFM-vendor-defunct'` confirms the original feed source no longer exists. The table is actively used (per system description) but no replacement feed is documented. - Risk if violated: The table may contain only historical records. Operations staff may be querying stale data without knowing it. - Validation target: Operations team; IT infrastructure owner. **Assumption 3: `meter_id` in `meter_readings` resolves to a valid asset** - Evidence: `meter_id` is a FK with no target table in the documented schema. Billing depends on reading records being correctly associated with a customer's metered asset. - Risk if violated: Orphaned readings produce incorrect or missing invoice amounts. The join path from reading → customer breaks silently. - Validation target: Database administrator or whoever runs the meter-reading ingestion process. **Assumption 4: Billing period logic is handled entirely in application code** - Evidence: No stored procedure, trigger, or scheduling entity appears in the schema. The invoice table has `billing_period` as a field but no generation-trigger mechanism is documented. - Risk if violated: If the application layer is modified or replaced without understanding the billing logic, invoice generation breaks. The logic is invisible to anyone who only sees the schema. - Validation target: Any developer who has touched the application layer since the original developer left. **Assumption 5: `controlled_access_log` satisfies active compliance obligations** - Evidence: The log exists and records user actions, but retention policy, log completeness, and whether it meets any regulatory standard (e.g., energy sector audit requirements) are not documented. - Risk if violated: The organization may believe it has an audit trail that regulators would accept when it does not — or the log may be complete but unverified. - Validation target: Compliance officer; legal team. --- ## Section 6 — Temporal Currency Flags | Item | Why It Is Temporal | Verification Required | |---|---|---| | `maintenance_log.source_system = 'WFM-vendor-defunct'` | Vendor went defunct in 2022. Records created before that date may reflect an operational state that no longer exists. | Confirm last valid record date; identify whether any records post-2022 exist and how they were created. | | `assets.installed_date` | Asset ages affect whether assets are still active, replaced, or decommissioned. No retirement field exists. | Cross-check against any external asset register to confirm which records are still live. | | `addresses.pole_id` | Pole assignments change when infrastructure is modified. No `last_updated` field exists on `addresses`. | Confirm with network/infrastructure team whether address-to-pole mappings are current. | | `customer_assets.end_date` (NULLs) | NULL `end_date` is treated as "active," but with no update process documented, stale open records may exist. | Query for customer-asset associations with `start_date` older than reasonable operational thresholds and validate against active accounts. | | `invoices.status` | Status values represent a workflow state (presumably: generated → sent → paid/overdue). Without valid status definitions, downstream consumers cannot interpret the field reliably. | Document the valid status values and their meanings as of the current date. | | System ownership | The original developer left 4 years ago; vendor defunct since 2022. Current maintainer is unknown. | {TEMPORAL: verify currency as of 2026-04-19 — confirm who currently holds operational responsibility} | --- ## Section 7 — Profile Confidence Self-Assessment **Coverage: Medium** The schema is reasonably complete and yields a solid entity map, data flow skeleton, and relationship inventory. The system description is specific enough to identify the ad-hoc maintenance-tracing use case, which is the most significant out-of-scope drift in the profile. However, two major structural gaps limit confidence: 1. No vendor documentation exists. The vendor is defunct. This means any behavior that resided in vendor-supplied components (billing calculation logic, PDF generation, the WFM feed) is invisible from available inputs. 2. The application layer is entirely undocumented. Billing period logic, status transitions, meter-reading aggregation, and the PDF generation mechanism are all assumed to exist in code that no current team member may fully understand. **Gaps by section:** - **Section 1.3** — Integration boundaries are mostly inferred. The meter-reading ingestion source and the replacement (if any) for the WFM feed are unknown. - **Section 2.1** — `meter_id` target, `invoice.status` value set, and asset lifecycle are all unresolved. - **Section 4.3** — No current system owner is identified. This is the single highest-risk gap for Stage 2: without a known owner, there is no clear authority to validate inferences. **Recommended actions before running Stage 2:** 1. Interview the operations team lead to confirm the pole-tracing workflow in detail — specifically how `maintenance_log` is currently populated post-vendor-shutdown. 2. Identify and interview whoever currently maintains the application layer (if anyone), focusing on billing calculation logic and invoice status transitions. 3. Run a database query to determine: (a) the most recent `maintenance_log.created_at` value, (b) the distribution of `invoice.status` values, and (c) whether any `meter_id` values in `meter_readings` are absent from `assets`. 4. Obtain the current network/infrastructure team's asset register and compare it against `assets` and `addresses.pole_id` for currency. --- *═══════════════════════════════════════════════════════════════════════════* *END STAGE 1 OUTPUT* *═══════════════════════════════════════════════════════════════════════════*