Sign-Air Hands-on Session
April 15th, 2026
Tasks 1–6 of this tutorial were originally presented at the Sign-Air Hands-on Session in Bologna, October 24th 2025. They have now been converted into an online hands-on session available to anyone on the Sign-Air website. Tasks 7–10 cover the Post-Settlement and Disruption Management features, added as a continuation of the original session.
Task 1: Get Invited to SignAir
Apply for a SignAir invitation and set up your account for the session.
- Use an email you can access.
- Decide roles (airline/railway TSP).
- Select Italy as the country.
- Enter invitation code: to be revealed at the venue.
Task 2: Finish Onboarding Wizard
Complete the onboarding process to activate your account fully.
Task 3: Specify Data Available for Sharing
Define which data your TSP can share for smart mobility purposes.
Task 4: Search for Partner TSP
Discover potential partner TSPs based on mobility goals and submit negotiation invitations.
- Connect to an already known TSP.
- Let the platform search for suitable candidates based on your search criteria.
Notes for this exercise:
- Specify Single Ticket as the mobility goal (this is our test scenario).
- Select Any country allowed checkbox, or choose Italy from the country dropdown.
- Select all time periods: Morning, Afternoon, Night.
- For the hub, select our test hub: Airport of Bologna. Start typing BLQ (IATA code) in the "Select hub" field.
- Select the TSP type of your partner participant (Regional/Long Distance Rail / Airline).
Task 5: Contract Negotiation
Negotiations on Data Sharing Agreements and Smart Contract.
Task 6: Timetable Synchronization
Gain insights from uploaded timetables and identify potential links for single-ticketing.For this exercise, sample timetable datasets have been prepared:
- The railway TSP representative can download a sample GTFS file based on the timetable published by Trenitalia here.
- The airline TSP representative can download one of the following sample timetable CSV files, created from real flight schedules from March 2022:
Task 7: Review Your Signed Contracts
Explore the contracts resulting from the completed negotiation process.The signature workflow (Signatures section) is where each party applies their digital signature to finalise a contract. Once both parties sign, the negotiation status becomes SIGNED and the contract appears in the Contracts section. You can explore the Signatures section independently, but we will not reproduce it step by step here.
| TSP Inviter | TSP Recipient | Goals | Status | Actions |
|---|---|---|---|---|
| Renfe | Lufthansa | Single ticket | ⊙ SIGNED | Read Contracts |
| Renfe | Vueling | Single ticket | ⊙ SIGNED | Read Contracts |
| Renfe | Iberia | Single ticket | ⊙ SIGNED | Read Contracts |
| Air Europa | Renfe | Single ticket | ⊙ SIGNED | Read Contracts |
The Single Ticket use case is the only one fully developed end-to-end in this demo, including the Post-Settlement dashboard and disruption management. This is why all four contracts share the same goal.
| Document name | Document type | Peer | Status |
|---|---|---|---|
| SmartContractforSingleTicket.pdf | Smart Contract | Lufthansa | SIGNED |
| SmartContractforSingleTicket.pdf | Smart Contract | Vueling | SIGNED |
| SmartContractforSingleTicket.pdf | Smart Contract | Iberia | SIGNED |
| SmartContractforSingleTicket.pdf | Smart Contract | Air Europa | SIGNED |
Task 8: Explore the Post-Settlement Dashboard
Review joint ticket sales performance and revenue under a signed contract.9.95% normal · 90.05% disrupted
The high disruption rate (90.05%) is intentional in this demo. It has been set artificially so you can explore all disruption resolution flows without waiting for real incidents.
Task 9: Disruption Management
Explore how the platform automatically handles flight disruptions through smart contract logic.- ACCEPTED The passenger accepted the re-routing proposal. They are automatically reassigned to the new itinerary and the resolution is registered on the blockchain.
- REJECTED The passenger declined the proposal. The contract clauses define what happens next: whether compensation is triggered and which party is responsible.
- PENDING A proposal has been sent to the passenger via the Travel Companion app but no response has been received yet.
IF TicketSold (legA, legB) >= 1
REGISTER Disruption in PlatformDB
NOTIFY Disruption in PlatformDB
IF AffectedPassengers (legA, legB) >= 1
FETCH PassengerContactInfo
SEND Notification to Passengers
ON Event: PassengerResponse(ticketId, decision)
IF decision == ACCEPT
REGISTER Resolution on Blockchain
NOTIFY TravelCompanion: UpdateItinerary
IF decision == REJECT
FETCH CompensationClause
SEND CompensationAction to ResponsibleParty
These clauses were automatically generated from the natural language terms negotiated in Task 5. The platform translates agreed conditions into executable smart contract logic — no manual coding required from the TSPs.
Task 10: Verify Resolutions on the Blockchain
Inspect the immutable on-chain records of each disruption resolution.- Transaction hash: unique identifier of the transaction on-chain.
- Data hash: a hash of the resolution data ensuring tamper-proof storage.
- From address: the wallet address that submitted the transaction.
- Network: Infura Sepolia (Ethereum testnet used in this demo).
- Gas fee: cost of executing the smart contract transaction (e.g. 0.004044 ETH).
- Transaction status: confirmation the transaction was accepted on-chain.
- Timestamp: exact date and time of registration.
This completes the full Sign-Air workflow — from account setup and partner discovery, through contract negotiation and signature, joint ticket tracking, automated disruption resolution, and finally blockchain-backed proof of every execution.