Meeting 1: Gather basic principles

[edwinvandenbelt]

Have a look at: the README. We have to discuss & complete the principles.

HOMEWORK: Please respond in this discussion on the principles already named, but also with new ones. We have to gather them, to use them in the process to validate what we think is important.

[fredriklj]

I think these are very good starting points for our work. I guess we might tweak them later on when we gain more insights into our work.

Some aspects I was contemplating before reading the list (which are not specifically mentioned) was:

• Abstraction and complexity reduction (Part of "Easy to understand, implement and operate" and "Future proof" I believe)
• Fraud prevention/Revenue Assurance (Even if it is "Traveller first", this might be a make-it/break-it because of its impact on the PTAs and public transport in general)
• Data minimisation and privacy-by-design (As required by the general data protection regulation)

[fredriklj]

There is another aspect that I came to think of, which is sort of difficult to fit into the current basic principles, which might be of some significant importance. And that is to allow the PTAs to offer flexible pricing and customised products. To make public transport more attractive, customised offers and flexible pricing was identified (in SE) to be one of the top priorities.

If we would design this model to be too rigid or too slow-moving, that could hamper development of more flexible business models. I don't know right now how to phrase that niceliy into a principle, but lets keep it in mind.

[CGantert345]

I support that, the freedom to choose your business model is a high value and msut not be restricted by the API.

[edwinvandenbelt]

@fredriklj how do you see 'fraud prevention' within the scope of API design? Isn't it an overarching aspect, an ecosystem issue? The same applies to revenue assurance. Please clarify.

[fredriklj]

For example by never allowing the ticket vendor to be issuing tickets on the PTA's behalf, i.e. using a zero-trust model where the PTA always issues its own tickets and thereby knows exacly what tickets have been issued and are valid, and have their own information to make the settlement with the ticket vendors.

I'd say it relates to the roles and what responsibilites they have, which I believe inevitably will be reflected in the API.

[OlivierBigex]

I agree with the basic principles already suggested.
Maybe add a principle saying that EUDIT must be aligned with other EU/local reglementations or standards of the sector. Like TSI, PRR or ticketing standards (UNE EN 1545-1:2015 and FR variant INTERCODE).

[CGantert345]

Most of the basic principles are ok. I would not list the Transmolde on within the basic principles, as all others aim on reducing costs and serving the customer, Transmodel is more a tool than a goal.

The "Future Proof" principle combines two diverging aspects. One to use established technologies that will not disapear in near future (saves costs, ensures the availability of resources). And another aspect of looking into possible future technologies and not block their usage. Which is by nature unsecure (we all know dozens of promising furure technologies that finally failed). I would suggest to split the point.

Amount the Techilities the Extensibility: is listed twice.

[edwinvandenbelt]

@einarbjorkevoll nice typo: "as fare as possible". I think you mean 'as far as possible'

[edwinvandenbelt]

And, @CGantert345, what do you mean with 'the sector'?

[CGantert345]

https://www.cer.be/

[edwinvandenbelt]

CER only covers the railway undertakings. We have to create something that breaks down the silo walls.

[CGantert345]

https://digitaltraveleu.wbresearch.com/mediapartners/ettsa

[TuThoThai]

Sugestion to rephrase Traveller/customer to Traveller and Customer to clarify that a customer != Traveller in some cases

[TuThoThai]

Agreed principles as of 24 February 2026 (refer to meeting notes for more details):

1. Main basic principles

• Traveller and Customer first​​
• Transmodel based​​
• Do not reinvent the wheel​
• Low threshold for adoption​
• Reasonable implementation costs for all

2. Second-level basic principles

• Easy to understand, implement and operate
• Functionality above technique
• GDPR: Data minimalization and privacy-by-design​​
• Decentralized
• Aligned with EU regulations, including Data Act, MMTIS, TSI telematics, etc.

For the detailed definition, it was noted that "Easy to understand, implement and operate" should mention that the reduction of complexity should not hinder the representation of what is complex and cannot be changed.

All others are removed and the list of "ilities" are moved toward a check-list to use during the forge

[TuThoThai]

As of 10 March 2026, this conversation will be closed as soon as there is the list of the EU regulations that will apply to this project

[edwinvandenbelt]

In other words, we can close this one, as soon we've clarified 'etc' & Odile wanted to comment in the meeting.

[edwinvandenbelt]

@oangeras Please post your remark as a comment you wanted to address!