Skip to content

Navigation Menu

Sign in
Sign up

Repository files navigation

Beamed Power Interface (BPI)

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.


Nobody has written this down

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:

  • ITU-R's only wireless-power Recommendation is scoped to phones and sensor networks
  • Report SM.2392-2 names the band and recommends nothing, because Reports do
  • the Radio Regulations carry no Article 21 space-to-Earth row for 5.8 GHz
  • WRC-27 has no agenda item, and ITU-R SG3 does not sit again until June 2027
  • IEEE's ICES lists no active projects; CCSDS has nothing power-related
  • no regulator surveyed has an open proceeding

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.

It is not only an Earth-surface problem. The same four agreements are needed by a supplier powering a client spacecraft, and by a rover in a permanently shadowed lunar crater where solar is unavailable by definition. The interface shape is identical; the numbers are not, and §1.1 says which of the three this document has actually derived.

The idea

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:

  • the token carries a power ceiling, so "curtail" and "continue" are one message and therefore one code path
  • its lifetime and the declared intruder speed set the keep-out buffer, so a timing parameter becomes 1,350 m of land you can see on a map
  • an SGP4 ephemeris is inadmissible as the pointing reference: a 2 km aperture at 547 km subtends 0.21°, and general-perturbations error exceeds that

What this is not

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.

Parts

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

Repository map

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

Reading order for a sceptic

  1. spec/00-status.md — what this document is not.
  2. gap-analysis.md — whether the gap it claims is real.
  3. OBJECTIONS.md — whether we know what is wrong with it.
  4. spec/05-interlock.md — the part that would matter.

Schema identifiers

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.

For implementers

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.

Run them against your own code in any language:

node tools/bpi-validate.mjs vectors --exec "./your-verifier"

Your program reads one vector as JSON on stdin and answers {"accepted": bool, "reason": string} on stdout. That is the entire contract — no library, no linkage, no language requirement. The rejection reason is checked too, so an implementation that refuses everything fails all ten vectors instead of passing eight. tools/README.md has the details, and bpi-validate claim will check your conformance claim before you open a pull request against §8.4.

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.

You owe us nothing, and we would still like to know

Implementing this specification requires no permission and no licence. Copyright covers a specification's text, not its ideas, and IPR.md [IPR-5] already grants a royalty-free, irrevocable patent licence to anyone implementing it. You can build a conformant system, sell it, and never mention this project. That is the outcome the licensing was chosen to allow, and asking you to notify anyone would have made it a different and worse licence.

So this is a request and explicitly not a condition:

  • Say you exist — a post in Implementers, or an issue, or a one-line email. Even "we read it and went another way" is useful.
  • Publish a conformance claim — copy conformance/claim-template.json, run node tools/bpi-validate.mjs claim yours.json, host it somewhere publicly readable (the author's own claim failed that test on 2026年08月30日 by living in a private repository), and open a pull request adding a row to §8.4. No gatekeeping, no review beyond checking it parses and enumerates the right identifiers.
  • Tell us what broke — a specification with one implementation has never been shown to be interoperable with anything, which is OBJECTIONS.md O-1 and the objection everything else waits on. You are the only person who can close it.

Nothing here is tracked, enforced, or checked. The only reason to do any of it is that a document nobody has ever contradicted is not the same as a document nobody can contradict.

Citing this

CITATION.cff carries the citation metadata and GitHub renders a Cite this repository button from it. Releases are signed tags, verifiable against conformance/keys/allowed-signers without trusting anyone's badge — see RELEASING.md.

Validating the schemas

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.

Measuring whether anyone uses this

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.

Contributing

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.

Where a comment goes

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 optical annex author — seven concerns differ from RF in kind, not magnitude, and ARAQYS-D3 flies both under one integrator in February 2027.
  • An RF safety review below 6 GHz — an hour on one section. The specification works in incident power density; below 6 GHz the basic restriction is SAR.
  • A second implementation — the objection everything else waits on. Signed vectors and the signing key are published so it can be done without talking to anyone.

An issue is equally fine, and a pull request against OBJECTIONS.md is better than either.

Licence

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.

About

Draft specification for the interface between a power-beaming spacecraft and the receiver it delivers to. Request for Comments — not a standard.

Topics

Resources

Contributing

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

AltStyle によって変換されたページ (->オリジナル) /