Storage Asset Ontology Agent

What it solves

Battery-storage operations require equipment and metering, market settlement, contracts, and financial definitions to agree. Matching display names do not establish asset ownership, while revenue variance may arise from availability, efficiency, or settlement timing. This personal prototype uses four synthetic sites and technical, market, contract, and financial ledgers to make the asset, period, and supporting evidence explicit in each analysis.

The system checks asset identity and data quality before versioned code calculates revenue, round-trip efficiency (RTE), debt-service coverage (DSCR), and state of health (SOH). The Agent orchestrates tools and explains results; missing data, unresolved identity, and conflicting definitions remain visible rather than becoming confident conclusions.

Core capabilities

Filter the scenario catalog by asset, period, and operational finding
Inspect technical, market, contract, and financial ledgers together
Calculate revenue bridges, RTE, DSCR, and SOH scenarios
Ask follow-up questions with facts, citations, snapshots, and tool traces
Review identity mappings and proposed actions manually
Publish gated operating packages and retain version replay

How it works

Check asset identity and the four ledgers
Calculate metrics and operational findings
Ask scenario questions and inspect evidence
Record human decisions and publish gated changes

The current workbench brings together the scenario catalog, Agent chat, asset hierarchy, ledgers, findings and evidence, revenue bridge, SOH scenarios, and mapping review. The default package exposes four sites and 15 findings; the catalog changes with an expanded synthetic package, while evaluation questions do not automatically become operating data. Scenario cards populate a question for the user to send. Responses expose status, sources, snapshots, and pending approval drafts.

Project highlights

Establish identity before explaining operating figures

RDF mappings distinguish source-system IDs from verified master assets. SHACL checks constraints and OWL RL derives supported relationships. A matching name cannot assign a settlement automatically: unresolved identity returns NEEDS_IDENTITY_REVIEW and invalid data returns INVALID_DATA. DSCR remains PROVISIONAL while reconciliation breaks persist, and a BMS estimate cannot replace a standard capacity test.

Keep calculations and evidence outside model generation

Deterministic code computes the revenue bridge and metrics; tools return facts, citations, periods, scope, and versions. The model organizes responses with fact placeholders, while the server renders and validates operating numbers. Users can trace conclusions to ledger records and contract clauses. Conversations retain a thread, but a changed package version starts a new evidence context.

Agent chat showing a provisional debt-service conclusion for a synthetic SPV, with facts, contract citations, and a snapshot — A repository screenshot captured on October 20, 2026 with synthetic data and a fake model. It demonstrates interaction and evidence structure, not live-model answer quality.

Separate analysis, approval, and publication

The revenue bridge decomposes budget-versus-actual variance into availability, volume, efficiency, price, ancillary services, penalties, and timing, avoiding the treatment of unsettled accruals as permanent losses. Mapping and parameter changes first become human decisions, then exported overlays. The CLI checks quality, competency questions, and expected differences before publishing a frozen package. Approval records a decision without executing trades, claims, or device control.

Revenue bridge for synthetic site Alpha, decomposing budget-to-actual variance into operating drivers and a residual — This synthetic Alpha revenue bridge uses figures and drivers calculated by code, not model estimates or real-project operating results.

System architecture

Architecture: four ledgers pass through identity mapping, a graph, and quality gates to produce deterministic facts; the Agent answers from evidence and human decisions enter a separate version-publication path — The repository's simplified flow diagram separates deterministic computation from approval and publication. The current scenario workbench and Agent chat reuse this core.

FastAPI serves a native HTML, CSS, and JavaScript workbench alongside query APIs. A LangGraph Agent invokes constrained tools; the graph, metric, and rule layers return traceable facts. Read-only queries are separate from review records, and the current operating package changes only after CLI gates pass. Snapshots retain input and code fingerprints. Replaying an older package under new code warns about code drift rather than restoring an old execution environment.

Project scope

This is a personal prototype using synthetic data, with private source code and no real EnOS or production-site connection. Business operations are read-only; approval records decisions without bidding, trading, controlling devices, or executing claims. Screenshots and workbench acceptance use a fake model. Separate live-model experiments exist, but passing a fixed-task programmatic scorer does not establish that every business answer is acceptable or that production performance is proven. Financial and dispatch models are simplified, and identity/authentication and audit mechanisms do not constitute a complete enterprise platform.