Vision and Scope

Goal

One scriptable command line tool for the everyday Peppol questions that today require a browser, three different web forms and a guess: is this participant registered, what can it receive, where, with which certificate, and is that certificate still trustworthy?

The tool serves two modes of use equally:

• Interactive — a support engineer answering a question about a live participant in seconds.
• Unattended — a CI job or monitoring script that checks registrations, certificate expiry and endpoint health, and fails the build on a regression. This is why stable --output json and distinct exit codes (see CLI Conventions) are core requirements rather than nice-to-haves.

It is a client and diagnostic tool. It inspects and administers the network's metadata; it does not participate in the network's message exchange.

In scope

Area	What it covers
Identifiers	Validate and normalise participant, document type and process identifiers; explain scheme rules, checksums and deprecations.
DNS / Discovery	Compute the participant hash and walk the full resolution chain step by step, so a failed lookup can be attributed to a specific step.
SML	Read and list your own SMP's registrations (authenticated, mTLS), register and delete SMPs and participants, and drive the two-step participant migration. Third-party lookups go through DNS, because the SML has no anonymous read interface.
SMP (read)	Service group listing, service metadata retrieval, signature verification, and the combined "can X receive Y?" answer.
SMP (write)	Manage participants and endpoints, including bulk import and export, through the phoss-SMP write API. Peppol SMP 1.4.0 standardises no write interface, so these commands live in their own phoss-smp area to keep the portability boundary visible.
Peppol Directory	Search, and fetch a participant's business card.
Certificates / PKI	Verify AP and SMP certificates against the Peppol CA chain, check expiry and revocation, extract the Seat ID, and provide keystore helpers.
Code lists	Browse, search and diff the Peppol code lists offline; flag deprecated entries.
Document validation	Validate a business document by sending it to a configured Phorm instance, with local document type auto-detection.

The detailed, per-command breakdown with status values is in the Feature Catalogue.

Out of scope

Excluded	Reason
AS4 sending and receiving	An AS4 message exchange needs a full AP context: a message-level configuration, signing and encryption keys, reliable message storage, retry handling and a reachable receiving endpoint. Reproducing that inside a short-lived CLI process would mean shipping a second, lesser AP implementation and inviting it to be used in production. The existing AP software is the right place for this. See ADR-001.
AS4 message inspection	Same root cause: it only becomes useful with the keys and message store of the AP that sent or received the message, which a stand-alone CLI does not have.
Mock AP / test receiver	A mock receiver has to be a long-running, publicly reachable server with a valid certificate. That is a deployment, not a command.
Other networks — DBNAlliance, HR eDelivery, generic OASIS BDXR SMP deployments	This is a Peppol tool. The libraries underneath support other networks, but exposing them would qualify the meaning of nearly every command and double the option and test matrix, for an audience that is already served by using the libraries directly. See ADR-007.
TSR / EUSR reporting submission	Transaction Statistics and End User Statistics reports are derived from an AP's own message history and are submitted under that AP's identity. The CLI has neither the data nor the identity, and a tool that submits plausible-looking reports on the operator's behalf is a liability. See ADR-002. > TODO(verify): the exact current names, versions and submission channel of the TSR/EUSR reporting specifications

Out of scope is not the same as forbidden forever — it means it will not be planned here, and re-opening it requires a new ADR in Decisions.

Target users

• AP and SMP operators — verifying their own registrations and certificates, and administering SMP content.
• Integrators — figuring out why a document will not reach a receiver.
• Support engineers — answering participant questions without a development environment.
• CI pipelines — regression-checking registrations, expiry dates and endpoint health.

Separate topic

A GraalVM native image would change startup time, distribution and packaging considerably. It is explicitly not planned on this page; it is tracked as question 1 in Open Questions.