Reference
Changelog
The breaking-change policy and the versioned tokens that gate compatibility.
This page fixes how Tekmerion's public contracts change and how versioned tokens let an integration stay correct across changes. Dated contract entries are added here as changes ship.
No breaking contract changes have been recorded since launch. Dated entries are added here as changes ship; the policy below governs them.
What counts as a change
| Class | Definition | How it ships |
|---|---|---|
| Additive | A new optional field, a new enum value on a surface documented as extensible, or a new endpoint. | May ship without a version bump. Your integration MUST tolerate unknown additive fields and unknown enum values it does not recognise. |
| Breaking | Removing or renaming a field, changing a field's type or meaning, tightening validation, or changing a fixed wire format. | Gated behind a versioned token (below). The prior version's behaviour is not altered in place. |
Versioned tokens
Three independent tokens version the public wire contracts. Each is authoritative for the artifact or request that carries it.
| Token | Where it appears | Versioning rule |
|---|---|---|
Signature version v1 | The X-Tekmerion-Signature header value, as the v1= prefix on every signed notification. | Identifies the signing wire format. A receiver MUST reject a token it does not implement (for example a future v2=). A new signing format ships under a new token, never by changing v1. See Signature verification. |
PoP schema_version | The envelope of every Proof-of-Payment artifact. | Defines the layout and meaning of that artifact's data. A published version is immutable; an artifact is read under exactly the version it carries, never under the latest. See Schema versioning. |
Signing key id kid (pop-signing-v{N}) | The envelope of every Proof-of-Payment artifact. | Identifies the key version that signed the artifact. Assigned sequentially with no gaps and immutable once assigned. See Signing and key discovery. |
Compatibility guarantees
| Guarantee | Statement |
|---|---|
| Per-artifact interpretation | A Proof-of-Payment is interpreted under the schema_version it carries. Artifacts under an older version remain interpretable under that version indefinitely. |
| No silent reinterpretation | A field's meaning does not carry across versions. Pin interpretation to the token the artifact or request names. |
| Forward tolerance | An integration MUST verify a signature it can (signing is version-independent of the PoP schema) and interpret the fields it recognises under the named version, without assuming the layout of a version it has not implemented. |
| Reject unknown wire versions | A signature whose version token is unknown MUST be rejected, not best-effort parsed. |
Reading this page
When a dated entry is added, it states the change class, the surface affected, and — for a breaking change — the token that gates it. An integration that follows the forward-tolerance rules above absorbs additive entries without action and adopts breaking entries by moving to the new token.