Public records and engineering validation
Claims you can inspect.
This page separates public company records, inspectable engineering work and third-party testing from outcomes that still have to be proven in a deployment.
How to read this page
Each item identifies the available source, what it supports and where the evidence stops.
Evidence types
Four distinct signals, without treating one as proof of another.Public record
R&D projectofficial programme resultParticipation
OCA listingcurrent public statusEngineering
Source coderepository and historyTesting
ISO 15118-20third-party equipmentEvidence ledger
What the public record supports.
These sources establish company activity and engineering work. They do not substitute for product certification, universal compatibility or measured customer outcomes.
Official programme record
EU-supported R&D project
Romania's official programme results list VAMPIRE PAY SRL and project 336957 for an interoperable EV charging management, authentication and payment solution.
Boundary: the record confirms the project and its stated scope; it does not prove deployment scale or commercial results.
Open the official result (PDF) ↗Standards participation
Open Charge Alliance participant
The OCA directory lists Vampire.Energy as a participant in Romania and currently identifies it as non-certified.
Boundary: participation establishes involvement in the OCA ecosystem; it is not an OCPP product certification.
Open the OCA participant record ↗Inspectable engineering artefact
Public OCPP gateway work
The RabbitMQ Web OCPP repository exposes source, commit history and releases for a message-oriented OCPP gateway.
Boundary: the repository supports an engineering-capability claim; it does not establish an installed base or a deployment-independent capacity figure.
Inspect the public repository ↗Third-party interoperability work
ISO 15118-20 communication on an AC charger
Keysight reports that its EV-EVSE communication tester validated standards-based ISO 15118-20 communication with an AC charger implementation developed by Vampire.Energy. The AC hardware was provided by Astreea.
Boundary: this supports the tested communication path and implementation; it is not a claim of universal vehicle, charger or conformance-test coverage.
Read the Keysight record ↗ Read the Astreea demonstration record ↗Responsibility boundary
The product is software. The charging system is larger.
Vampire.Energy can observe charging context and apply software control, but a live charging service still depends on the charger, certified components, installation and operator processes around it.
Vampire.Energy software
Platform logic, charger communication, remote intervention, observability and the integrations selected for a deployment.
Charger and certified components
Electrical design, certified metering hardware, charger certification and device-level safety remain with the relevant manufacturer and components.
Installation and operation
Electrical installation, tariff configuration, operating policy and regulatory obligations remain with the installer and operator responsible for the service.
Deployment proof
The next proof comes from the operating environment.
Public evidence can establish that the work exists. It cannot predict the result of a particular charger estate, workload or operating model.
Capacity and performance
Throughput, response time and availability need a defined workload, architecture and acceptance test.
Estate compatibility
Protocol support does not guarantee identical behaviour across every charger, firmware version, vehicle and surrounding system.
Business outcome
Cost, uptime, utilisation, peak reduction and customer-experience results need a baseline and deployment-specific data.
Review the control layer against your architecture.
Bring the charger estate, operating requirement and surrounding systems. We will define what can be tested, what has to be integrated and how success will be measured.
Plan a technical review arrow_forward