Draft specification for the interface between a power-beaming spacecraft and the receiver it delivers to. Request for Comments — not a standard.
1
stars
0
commits
JavaScript
primary language
Sep 7, 2026
updated
A draft specification for the interface between a power-beaming spacecraft and the receiver it delivers to.
Version 0.2.0-draft, unreleased · Last published 0.1.0-draft, 2026-08-22 · Request for Comments, not a standard
The RFC period closes 2026-11-30, when 0.2.0-draft is tagged and every comment gets a published disposition. What has changed since 0.1.0-draft is in conformance/requirement-diff.md, generated rather than written.
A spacecraft beaming power to a receiver it does not own has to agree four things with that receiver: what each side can do, when delivery happens, how the beam is kept safe while it is radiating, and how much energy actually arrived. No published specification covers any of it.
Checked, with dates and sources, in gap-analysis.md:
Meanwhile at least seven programmes are building it across two incompatible physical layers, and one 2027 flight carries five power-beaming payloads from different companies on a single bus. That is the condition in which interfaces get frozen by accident, one bilateral integration at a time.
Enable is unanimous. Abort is unilateral.
Power flows only while both segments continuously consent, expressed as a stream of short-lived signed tokens, so the absence of consent is the default state. A naive interlock has the ground tell the spacecraft to stop, which needs a message to arrive during exactly the failure that stops messages arriving. Inverting it makes silence safe.
Most of the rest follows from that:
It is not a standard. No standards body has published, reviewed, endorsed or been
asked about it. It has one implementation. Several of its numbers are proposals rather
than measurements, and OBJECTIONS.md lists the strongest arguments
against it that its own authors could construct — eight of them open, one with no
mitigation offered. Read spec/00-status.md before anything else.
It does not grant, imply or substitute for any regulatory permission. A system can be fully BPI-conformant and hold no authorisation to transmit at all. The specification is designed to make that state declarable rather than to prevent it.
| Part | Title | Status at 0.1 |
|---|---|---|
| BPI-C | Core — information model, session lifecycle, conventions | Normative |
| BPI-S | Safety Interlock | Normative |
| BPI-M | Metering & Settlement | Normative |
| BPI-A | Regulatory & Exposure Attestation | Normative |
| BPI-RF | Annex — RF microwave physical layer | Normative |
| BPI-OPT | Annex — Optical / NIR physical layer | Reserved, stubbed |
| BPI-CONF | Conformance framework | Normative |
spec/ the specification, in reading order
schemas/0.2/ JSON Schema (draft 2020-12) for every message
profiles/ every tunable number, outside the normative prose
examples/ worked messages, valid and deliberately invalid
conformance/ the requirement register and claim template
gap-analysis.md why this is not already covered — dated, with URLs
OBJECTIONS.md arguments against this draft
DISPOSITIONS.md what we did about every comment received
spec/00-status.md — what this document is not.gap-analysis.md — whether the gap it claims is real.OBJECTIONS.md — whether we know what is wrong with it.spec/05-interlock.md — the part that would matter.Schemas are identified and served under:
https://beamdesk.github.io/beamed-power-interface/schemas/0.2/<name>.schema.json
Earlier drafts used https://bpi.spec/…, which was a mistake: .spec is not in the
IANA root zone, so that identifier could never resolve and any validator configured to
fetch a $ref by $id would fail. $id is not required to be dereferenceable, but one
that cannot be is a dead end for tooling and a small lie to a reader.
Internal $refs are relative, so a copy of schemas/0.2/ validates offline with no
network access at all.
conformance/vectors/ carries signed token-chain vectors. Each
states the expected verdict and every reason a conformant verifier might legitimately
give, so you can check your implementation against this specification without talking to
anyone. The signing key is published in conformance/keys/ on
purpose, so the vectors can be regenerated rather than only verified.
reference/ is the interlock as executable code. It is the author's, so it
is not an independent implementation and does not close OBJECTIONS.md O-1.
npx --yes ajv-cli@5 validate --spec=draft2020 -s schemas/0.2/<name>.schema.json -d examples/<case>/<file>.json
tools/validate.sh # everything, including the must-fail cases
The invalid examples are part of the test surface: a power flux-density without its reference bandwidth, an exposure figure without its averaging time, and a position without its height reference must fail validation. If they pass, the schemas are broken.
adoption/digests/ records dated snapshots, written by tools/adoption-scan.sh.
GitHub discards traffic data after fourteen days, so a number nobody writes down is
gone.
The digest keeps two lists apart. Signals that cost somebody effort — an independent conformance claim, a second implementation, an external issue, a substantive comment — are the only ones that mean anything, and all are currently zero. Vanity metrics are recorded and labelled as such: on publication day this repository logged twelve clones from nine unique cloners and zero page views, which is the signature of automated scanners rather than readers.
The digest also carries a kill switch rather than a health bar. If gap-analysis.md
goes stale, or any row in it flips because a standards body opened a work item, then
adoption of this document stops being the goal — see spec/00-status.md.
Comments are wanted, especially the ones saying this is wrong. See
CONTRIBUTING.md and GOVERNANCE.md. Every
substantive comment gets a public disposition in DISPOSITIONS.md,
including the ones we reject and why.
The RFC period closes 2026-11-30, when 0.2.0-draft is tagged and every comment has a published disposition.
Discussions has four categories and there is a thread open on each part of the specification, each one naming what that part gets wrong rather than asking for general feedback.
| Category | For |
|---|---|
| RFC comments | Comments on the draft. Five threads, one per part. Every comment gets a published disposition by 2026-11-30. |
| Implementers | Questions from people building against BPI. An accepted answer is the closest thing this draft has to an interop ruling. |
| Wanted | The three things this project cannot do itself |
| Announcements | Releases, the RFC close, published dispositions |
The three asks, each bounded and each addressed to a different person:
An issue is equally fine, and a pull request against OBJECTIONS.md is better than
either.
Dual licensed, deliberately. LICENSE is the authoritative statement.
| Half | Licence | Full text |
|---|---|---|
Specification prose — spec/, and the top-level .md files | CC BY 4.0 | LICENSE-TEXT |
| Schemas, examples, profiles, tooling | Apache-2.0 | LICENSE-CODE |
The prose is attribution-only so it can be quoted, translated and forked — and so a standards body that later adopts it is not blocked by the licence. The code half is Apache-2.0 for its patent grant, which is not theoretical in a field dense with retrodirective-array and rectenna patents.
Every file carries an SPDX-License-Identifier, so the split is machine-readable and
not merely asserted here.
Contributors disclose known essential patents and grant a royalty-free licence over
their own contributions, under IPR.md. No patent search has been performed
and no essentiality claim is made, and that policy does nothing about a third party's
patent. See IPR.md §1 and §6. Automated tools report one licence per repository
and will pick one of the two; neither answer is complete.
JavaScript
74.1%
Shell
23.1%
Python
2.8%
Draft specification for the interface between a power-beaming spacecraft and the receiver it delivers to. Request for Comments — not a standard.
1
stars
0
commits
JavaScript
primary language
Sep 7, 2026
updated
A draft specification for the interface between a power-beaming spacecraft and the receiver it delivers to.
Version 0.2.0-draft, unreleased · Last published 0.1.0-draft, 2026-08-22 · Request for Comments, not a standard
The RFC period closes 2026-11-30, when 0.2.0-draft is tagged and every comment gets a published disposition. What has changed since 0.1.0-draft is in conformance/requirement-diff.md, generated rather than written.
A spacecraft beaming power to a receiver it does not own has to agree four things with that receiver: what each side can do, when delivery happens, how the beam is kept safe while it is radiating, and how much energy actually arrived. No published specification covers any of it.
Checked, with dates and sources, in gap-analysis.md:
Meanwhile at least seven programmes are building it across two incompatible physical layers, and one 2027 flight carries five power-beaming payloads from different companies on a single bus. That is the condition in which interfaces get frozen by accident, one bilateral integration at a time.
Enable is unanimous. Abort is unilateral.
Power flows only while both segments continuously consent, expressed as a stream of short-lived signed tokens, so the absence of consent is the default state. A naive interlock has the ground tell the spacecraft to stop, which needs a message to arrive during exactly the failure that stops messages arriving. Inverting it makes silence safe.
Most of the rest follows from that:
It is not a standard. No standards body has published, reviewed, endorsed or been
asked about it. It has one implementation. Several of its numbers are proposals rather
than measurements, and OBJECTIONS.md lists the strongest arguments
against it that its own authors could construct — eight of them open, one with no
mitigation offered. Read spec/00-status.md before anything else.
It does not grant, imply or substitute for any regulatory permission. A system can be fully BPI-conformant and hold no authorisation to transmit at all. The specification is designed to make that state declarable rather than to prevent it.
| Part | Title | Status at 0.1 |
|---|---|---|
| BPI-C | Core — information model, session lifecycle, conventions | Normative |
| BPI-S | Safety Interlock | Normative |
| BPI-M | Metering & Settlement | Normative |
| BPI-A | Regulatory & Exposure Attestation | Normative |
| BPI-RF | Annex — RF microwave physical layer | Normative |
| BPI-OPT | Annex — Optical / NIR physical layer | Reserved, stubbed |
| BPI-CONF | Conformance framework | Normative |
spec/ the specification, in reading order
schemas/0.2/ JSON Schema (draft 2020-12) for every message
profiles/ every tunable number, outside the normative prose
examples/ worked messages, valid and deliberately invalid
conformance/ the requirement register and claim template
gap-analysis.md why this is not already covered — dated, with URLs
OBJECTIONS.md arguments against this draft
DISPOSITIONS.md what we did about every comment received
spec/00-status.md — what this document is not.gap-analysis.md — whether the gap it claims is real.OBJECTIONS.md — whether we know what is wrong with it.spec/05-interlock.md — the part that would matter.Schemas are identified and served under:
https://beamdesk.github.io/beamed-power-interface/schemas/0.2/<name>.schema.json
Earlier drafts used https://bpi.spec/…, which was a mistake: .spec is not in the
IANA root zone, so that identifier could never resolve and any validator configured to
fetch a $ref by $id would fail. $id is not required to be dereferenceable, but one
that cannot be is a dead end for tooling and a small lie to a reader.
Internal $refs are relative, so a copy of schemas/0.2/ validates offline with no
network access at all.
conformance/vectors/ carries signed token-chain vectors. Each
states the expected verdict and every reason a conformant verifier might legitimately
give, so you can check your implementation against this specification without talking to
anyone. The signing key is published in conformance/keys/ on
purpose, so the vectors can be regenerated rather than only verified.
reference/ is the interlock as executable code. It is the author's, so it
is not an independent implementation and does not close OBJECTIONS.md O-1.
npx --yes ajv-cli@5 validate --spec=draft2020 -s schemas/0.2/<name>.schema.json -d examples/<case>/<file>.json
tools/validate.sh # everything, including the must-fail cases
The invalid examples are part of the test surface: a power flux-density without its reference bandwidth, an exposure figure without its averaging time, and a position without its height reference must fail validation. If they pass, the schemas are broken.
adoption/digests/ records dated snapshots, written by tools/adoption-scan.sh.
GitHub discards traffic data after fourteen days, so a number nobody writes down is
gone.
The digest keeps two lists apart. Signals that cost somebody effort — an independent conformance claim, a second implementation, an external issue, a substantive comment — are the only ones that mean anything, and all are currently zero. Vanity metrics are recorded and labelled as such: on publication day this repository logged twelve clones from nine unique cloners and zero page views, which is the signature of automated scanners rather than readers.
The digest also carries a kill switch rather than a health bar. If gap-analysis.md
goes stale, or any row in it flips because a standards body opened a work item, then
adoption of this document stops being the goal — see spec/00-status.md.
Comments are wanted, especially the ones saying this is wrong. See
CONTRIBUTING.md and GOVERNANCE.md. Every
substantive comment gets a public disposition in DISPOSITIONS.md,
including the ones we reject and why.
The RFC period closes 2026-11-30, when 0.2.0-draft is tagged and every comment has a published disposition.
Discussions has four categories and there is a thread open on each part of the specification, each one naming what that part gets wrong rather than asking for general feedback.
| Category | For |
|---|---|
| RFC comments | Comments on the draft. Five threads, one per part. Every comment gets a published disposition by 2026-11-30. |
| Implementers | Questions from people building against BPI. An accepted answer is the closest thing this draft has to an interop ruling. |
| Wanted | The three things this project cannot do itself |
| Announcements | Releases, the RFC close, published dispositions |
The three asks, each bounded and each addressed to a different person:
An issue is equally fine, and a pull request against OBJECTIONS.md is better than
either.
Dual licensed, deliberately. LICENSE is the authoritative statement.
| Half | Licence | Full text |
|---|---|---|
Specification prose — spec/, and the top-level .md files | CC BY 4.0 | LICENSE-TEXT |
| Schemas, examples, profiles, tooling | Apache-2.0 | LICENSE-CODE |
The prose is attribution-only so it can be quoted, translated and forked — and so a standards body that later adopts it is not blocked by the licence. The code half is Apache-2.0 for its patent grant, which is not theoretical in a field dense with retrodirective-array and rectenna patents.
Every file carries an SPDX-License-Identifier, so the split is machine-readable and
not merely asserted here.
Contributors disclose known essential patents and grant a royalty-free licence over
their own contributions, under IPR.md. No patent search has been performed
and no essentiality claim is made, and that policy does nothing about a third party's
patent. See IPR.md §1 and §6. Automated tools report one licence per repository
and will pick one of the two; neither answer is complete.
JavaScript
74.1%
Shell
23.1%
Python
2.8%