A Grid Record documents one event in a property’s connection to the electricity network. Each kind of Grid Record has its own definition of what it asserts, and this version of the specification defines one kind: a record of a G98 notification. Every Grid Record issued so far is of that kind, and everything below describes it. A record states its kind in recordType (section 9).
A Grid Record of a G98 notification is a durable, independently checkable record that a notification under Engineering Recommendation G98 (“connect and notify”) was submitted to a named distribution network operator, for a named property, on a named date, under the application reference the ENA Connect Direct platform returned.
It is issued at the moment a filing succeeds, it is not tied to any account, and checking one requires no login, no relationship with OurOrb Energy and no payment.
A record exists only where a notification was actually filed. Where a notification could not be submitted through Connect Direct - and the customer was given documents to send to their network operator themselves - no record is issued, because there is nothing yet to attest.
Precisely these things, and nothing beyond them:
A record id is crt_ followed by 32 lowercase hexadecimal characters - 128 bits of entropy.
The identifier is the access control. There is no lookup by address, postcode, name or owner. There is no list endpoint, and no search. A record can be checked only by someone who has been given its id.
This is a deliberate design decision, not a missing feature. A searchable register of which properties have generation installed is a different product carrying different obligations, and this is not that product. Unknown ids and malformed ids are answered identically, so checking an id reveals nothing beyond what holding it already proves.
Every record carries a mode.
Mode resolution fails closed. Where a record’s mode cannot be established with certainty it is recorded as test. A record may understate itself; it will never overstate itself. On the verification page a test record receives this warning treatment instead of the confirmation - never alongside it, because a confirmation with a caveat underneath is how a screenshot misleads someone.
Every Grid Record carries the family of device its notification covers, and the class is part of the published record in section 9 from version 1.4.
It was previously withheld, on the stated reasoning that a field carrying the same value on every record tells a verifier nothing, together with an undertaking to publish it when a second class was first issued. Battery storage files as generation_demand - a battery both generates and draws - so a second class now exists and that undertaking has been met. Every record issued before 10 September 2026 reads generation, which is what those installations were.
Further classes are reserved for other device families. A class is only issued once the wording appropriate to it has been settled, because “submitted, never approved” is true of connect-and-notify processes and is not true of processes that involve an application and an approval. A record will never carry wording that is wrong for the process it describes.
A record that turns out to be wrong is revoked, not deleted. A revoked record keeps resolving and keeps serving its contents, marked as withdrawn with the date and, where one was given, the reason.
This is deliberate. Someone holding the id learns that the record was withdrawn, rather than meeting a “not found” that could equally mean they mistyped it. Only the first revocation takes effect: a record cannot be un-revoked, and a revocation reason cannot be rewritten afterwards.
No MPAN. No name. No email address. No telephone number. No payment information. No copy of the submitted form.
A record holds only the fields listed in section 9 - the minimum that makes it useful to someone checking it. The underlying submission record does contain personal data, and is anonymised 90 days after it is created; a record is deliberately excluded from that anonymisation, and cannot be issued once it has run.
That asymmetry is the design, not a side effect. The personal data behind a notification has a deliberately short life; the record that the notification happened does not. A record issued today is intended to still resolve, and still say the same thing, long after the submission behind it has been anonymised - which is the case a permanent record has to be able to make.
A Grid Record is not anonymous, and we do not claim it is. An installation address and postcode relate to the people at that property, so a record is personal data and we treat it as such. It is kept on the basis of our legitimate interest in maintaining a durable record that third parties can rely on: a record that could be erased on request would not be one. Three things keep that proportionate - a record is reachable only by someone given its identifier, there is no search of any kind (section 4), and it carries none of the fields named at the top of this section.
If you are an occupier of a property named on a record and you object to it being published, write to support@ourorb.energy. We will consider the objection on its merits and reply. Objecting is not the same as asking for a correction - a record that is wrong is withdrawn under section 7, and withdrawal is never deletion.
The verification page and the machine-readable endpoint serve the same projection, so the human answer and the software answer cannot diverge.
| id string | The record identifier (see section 4). |
| mode live | test | Which ENA environment the notification was filed to (see section 5). |
| recordType g98_notification | Which kind of Grid Record this is, and so which definition applies to it (see section 1). g98_notification is the only kind this version defines. Read it before relying on a record: a kind added later will assert different things, and a reader that meets a value it does not recognise should not interpret the record under this section. |
| applicationId string | The application reference returned by ENA Connect Direct. |
| dnoName string | null | The network operator the notification was submitted to. Nullable from version 1.5: where the operator cannot be identified with confidence the field is absent and the verification page omits the row, rather than carrying a placeholder. It names an independent network operator (an IDNO) where the property is served by one. |
| addressLine1 string | First line of the installation address. |
| postcode string | Postcode of the installation address. |
| deviceClass generation | demand | generation_demand | Which family of device the notification covers. generation is generating plant such as solar PV; generation_demand covers battery storage, which both generates and draws. Every record issued before 10 September 2026 reads generation, which is what those installations were. |
| systemWatts number | null | Declared total system output in watts, where recorded. |
| productName string | null | The declared inverter manufacturer and model, where recorded. |
| tenantDisplayName string | The organisation that filed the notification. |
| installedBy string | null | The business declared as having carried out the installation, where one was named. This is not the same claim as tenantDisplayName above: it names who did the work, not who submitted the notification, and unlike that field it is a declaration we have not verified (see section 3). Absent when the installation was self-installed, when no business was named, or where only an individual was given - an individual’s name is never published here. |
| filedAt ISO 8601 | When the notification was submitted. |
| issuedAt ISO 8601 | When this record was issued. |
| revokedAt ISO 8601 | null | When the record was withdrawn, if it was (see section 7). |
| revokedReason string | null | The reason for withdrawal, where one was given. |
| cdStatus string | null | The application’s status on the ENA Connect Direct platform, reproduced verbatim when known. This is Connect Direct’s statement, not OurOrb Energy’s or the network operator’s: some statuses report an operator decision (for example DNO Approved), others Connect Direct’s own processing (for example Auto-Approved, or any status beginning Failed - see section 3). Corrected in version 1.6; earlier versions described this field as the operator’s own status. Its absence means only that no status has been reported. |
| cdStatusRecordedAt ISO 8601 | null | When OurOrb Energy first recorded the current cdStatus. Status is checked periodically, so this is when the status was observed, which can be some hours after Connect Direct set it. Absent when there is no status, or where the status was recorded before version 1.6. |
As a person. Open https://verify.ourorb.energy/check/{id}, or paste the id - or a whole record link - at /check.
In software. GET https://api.ourorb.energy/v1/records/{id} returns the section 9 record as JSON with HTTP 200. No API key, no account, no charge. Cross-origin browser requests are permitted. Unknown or malformed ids return 404. Responses may be cached for up to 60 seconds, so a withdrawal propagates within a minute.
Verification is free and unmetered by design. A verification layer that required an account would only ever be checked by our own customers, which would defeat the point of having one.
This specification is versioned. Changes are additive: new fields and new device classes increment the minor version, and anything already defined keeps the meaning it had. If a definition ever had to change meaning, that would be a new major version, and records would continue to be interpreted under the version they were issued against.
The behaviour described here is what the software does. Where this document and the software could ever disagree, that is a defect in one of them - please report it.
Questions about this specification, or about a record you have been given: support@ourorb.energy.
Grid Record Specification v1.7, 12 October 2026.