Hardware should remain useful

A customer should be able to understand what a purchased station can do, how it communicates and what is required to connect it to an approved alternative platform. Hardware should not become unusable merely because one software service changes.

That promise requires more than publishing a PDF. A durable openness policy has five parts.

1. Stable public semantics

Lifecycle events, field meanings, compatibility criteria and version rules should have stable canonical pages. Public documentation must be readable without an account and indexable on the CoreCharge domain.

2. Machine-readable contracts

Human prose and machine-readable contracts describe the same commands. The command catalog, AsyncAPI, JSON test vectors and reference code are public and directly usable with synthetic values.

3. Evidence before compatibility claims

Compatibility is recorded against a model family, controller revision, firmware release, transport profile and test date. Similar message names or transport choices do not prove plug compatibility.

4. A clear security boundary

Publishing a command is not granting access to a cabinet. Production credentials, assigned endpoints and real firmware artifacts remain private; every configuration, release or maintenance action remains authenticated, scoped and auditable.

5. Exportable operating records

Operators should be able to retain the records needed for support and reconciliation, subject to contract, privacy and retention rules. At minimum, the operating model should distinguish station state, rental state, payment state, return evidence and support actions.

The practical promise

CoreCharge aims to make evaluation and approved integration possible without creating an unsafe public control plane. This is the standard by which future documentation releases should be reviewed.