/**
 * Un identifiant Peppol est-il assez bien formé pour qu'on écrive son scheme ?
 *
 * ⛔ « Contient un `:` » ne suffisait pas, et « deux segments non vides » non plus
 * — les deux ont été essayés et démolis par une gate (GPR-1110) :
 *
 * | entrée | découpage | pourquoi ça passait |
 * | -- | -- | -- |
 * | `":x"` | scheme vide | aucun contrôle sur les segments |
 * | `"0208:"` | valeur vide | idem |
 * | `"GB:VAT"` | `{GB, VAT}` | **deux segments non vides** — le code du scheme copié SANS son identifiant |
 *
 * Le dernier est le piège : `GB:VAT` est exactement ce que `SCHEMES_BY_COUNTRY`
 * affiche comme `code`, donc le copier seul est l'erreur qu'un développeur
 * commet naturellement. Il produisait `schemeID="GB"`, hors CEF EAS code list.
 *
 * ⚠️ Le contrôle du scheme est SYNTAXIQUE, jamais une allowlist : quatre chiffres,
 * ou l'une des valeurs littérales que `BR-CL-25` admet. Un code publié après notre
 * version de la code list doit continuer de traverser — être plus strict que le
 * réseau est l'erreur symétrique, et la pire des deux (GPR-904).
 */
export declare function isWellFormedPeppolId(peppolId: string): boolean;
/**
 * Les schemes qu'un ENDPOINT (BT-34) ne peut pas porter — GPR-1116.
 *
 * ⚠️ `isWellFormedPeppolId` sert DEUX questions qui n'ont pas la même règle :
 * l'adresse d'une partie (`validateParty`, jugée par `BR-CL-25`) et le
 * bénéficiaire du paiement (`payeeParty`, jugé par `BR-CL-10`). `SEPA` est
 * légal pour le second et ne l'est pas pour le premier — la liste littérale
 * ci-dessus les mélange, par héritage.
 *
 * ⭐ La forme juste serait un paramètre `usage`, comme en porte déjà
 * `validatePeppolIdentifier` : « un identifiant se valide contre l'USAGE,
 * jamais dans l'absolu ». Cet export est le pas intermédiaire — il permet à un
 * appelant qui sait juger une ADRESSE de retirer ce qui n'en est pas une, sans
 * changer le verdict des appelants existants. Suivi : GPR-1128.
 */
export declare const NON_ENDPOINT_SCHEMES: ReadonlySet<string>;
/**
 * Sépare un identifiant Peppol en son scheme EAS **numérique** et sa valeur.
 *
 * ⛔ **Ne découpe PAS sur le premier `:`.** Mesuré sur la code list officielle
 * v9.7 : 98 des 105 formes symboliques portent un `:`. Découper par position
 * rendait `{ scheme: "GB", id: "VAT:123456789" }` pour un vendeur britannique —
 * le scheme hors CEF EAS code list (`BR-CL-25`, fatale) ET la valeur corrompue.
 * `GB:VAT` étant le code que `SCHEMES_BY_COUNTRY` RECOMMANDE au Royaume-Uni,
 * le défaut frappait quiconque suivait notre propre guidage.
 * ⚠️ Cette phrase a dit « le SEUL code » jusqu'à GPR-1041, qui a ajouté `0060`,
 * `0088` et `0199` pour les sociétés sous le seuil de TVA. Le motif du défaut
 * est intact — c'est la RECOMMANDATION qui le rendait atteignable, pas
 * l'exclusivité — mais l'exclusivité, elle, n'est plus vraie.
 *
 * ⭐ **Le scheme occupe au plus DEUX segments**, et ce n'est pas une prudence :
 * mesuré sur la v9.7, aucune forme symbolique ne porte plus d'un `:`. La VALEUR,
 * elle, n'est bornée par rien — d'où l'essai du candidat long d'abord, puis le
 * repli sur le court. L'ordre inverse ferait dépendre le point de coupe de la
 * valeur, ce qui est exactement le défaut qu'on ferme.
 *
 * ⚠️ Un scheme que la table ne connaît pas ressort **inchangé**, jamais en
 * exception : c'est la doctrine de `canonicalScheme` (GPR-904), et elle vaut ici
 * aussi. Un scheme numérique publié après notre version de la code list doit
 * continuer de traverser — être plus strict que le réseau est l'erreur
 * symétrique, et la pire des deux.
 */
export declare function parsePeppolId(peppolId: string): {
    scheme: string;
    id: string;
};
//# sourceMappingURL=peppol-id.d.ts.map