Sign-Air Hands-on Session

Available online · April 15th 2026

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.

1

Task 1: Get Invited to SignAir

Apply for a SignAir invitation and set up your account for the session.
The SignAir contracting module is primarily used by TSPs, i.e., their legal representatives, appointed administrators, or technical personnel. For this session, participants will work in pairs to simulate interaction between two TSPs: one representing a railway TSP and the other an airline TSP. To facilitate onboarding for this session only, participants can apply for an invitation to join the SignAir platform.
Step 1: Go to the SignAir home page: demo.sign-air.eu.
Step 2: Click "Don't have an account? Get invited!". Get invited screenshot
Step 3: Fill out and submit the invitation form:
  • 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.
Fill out invitation form
Step 4: Open the invitation email and follow the Accept Invitation link. Accept Invitation
Step 5: Set up a password and log in. Set up a password and log in
2

Task 2: Finish Onboarding Wizard

Complete the onboarding process to activate your account fully.
After accepting your invitation, you are now logged in as a legal representative (highest role). Before continuing to use the platform, you need to complete the onboarding process using the onboarding wizard. Follow the steps below in the wizard.
Step 1: Click on the Wizard link in the side menu. Start with the first step - Complete TSP.
Step 2: Fill in missing contact information (e.g., address, VAT number).
Step 3: Optionally appoint another user in wizard step 2. You can skip it for this exercise.
Step 4: Complete by signing the User Agreement and Terms & Conditions in wizard step 3.
Step 5: Complete the wizard by clicking the Complete button.
3

Task 3: Specify Data Available for Sharing

Define which data your TSP can share for smart mobility purposes.
Before proceeding to the partner discovery process, you need to specify which data your TSP is able to share for smart mobility purposes.
Step 1: Click on the Data link in the side menu. Data section
Step 2: Review the data fields.
Step 3: Select all fields for maximum discovery. Select all fields
Step 4: Save the selected data fields. Save data fields
4

Task 4: Search for Partner TSP

Discover potential partner TSPs based on mobility goals and submit negotiation invitations.
With your data fields specified, you are now ready to discover potential partners for different mobility goals. Given that only one TSP should initiate the negotiation, this task is only performed by the railway TSP.
Step 1: Click on the Negotiations link in the side menu.
Step 2: On the Negotiations page, you can see all active or pending contract negotiation processes or create a new one. Click the New Match button. New Match
Step 3: When searching for potential partner TSPs, you have two options:
  • Connect to an already known TSP.
  • Let the platform search for suitable candidates based on your search criteria.
You can use both options.

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).
Step 4: Select your partner TSP and submit the invitation. Select partner TSP
Step 5: Negotiation created. Click on the Edit button and proceed to the next task. Negotiation created
5

Task 5: Contract Negotiation

Negotiations on Data Sharing Agreements and Smart Contract.
In the negotiation module, you will be able to negotiate with your partner on the details of two Data Sharing Agreements (as data provider and consumer) and on the Smart Contract.
Step 1: Open the DSA and Smart Contract tabs. DSA and Smart Contract tabs
Step 2: Negotiable contract parameters appear as blue links. Click any blue link to open a modal where you can propose the parameter's content. Once a parameter is set it requires approval from the other partner.
Step 3: In addition to modifying existing legal clauses, partners can propose adding new (non-mandatory) clauses to further refine the contract. Click the plus button in the bottom-right corner and select a clause to add.
Step 4: Continue editing the three contracts. When you are ready, lock the negotiation and send it to your partner for review by clicking the paper airplane button in the bottom-right corner.
Step 5: The other partner can open the negotiation and review all proposed changes following the same procedure described in this task. The changed parameters will be displayed in red indicating they need to be approved by the other partner.
6

Task 6: Timetable Synchronization

Gain insights from uploaded timetables and identify potential links for single-ticketing.
In the timetable synchronization module, you can upload your timetables in GTFS format (railway, bus) or Eurocontrol Flight Export format (airlines, airports). The system runs an algorithm that calculates connectivity scores, helping you identify potential links that could be offered under a single-ticketing scheme.
Step 1: Open the Timetable Synchronization tab and upload your timetable file.

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:
Step 2: Once your timetable data is uploaded, lock the negotiation to grant your partner's TSP access so they can upload their corresponding timetable, as described in the previous step.
Step 3: When both timetables have been uploaded, the algorithm automatically runs and displays the results in a table.
Step 4: The participant with current access to contracting can rerun the algorithm by adjusting parameters such as the minimum and maximum connection time or the detour factor.
Step 5: Review the results and select the links you wish to include in the Smart Contract by using the checkboxes.
Step 6: The other partner reviews and approves the selected links.
7

Task 7: Review Your Signed Contracts

Explore the contracts resulting from the completed negotiation process.
In a real scenario, signing contracts requires completing the full negotiation for each agreement - not just the Smart Contract, but also the Data Sharing Agreements for both parties. Because going through every clause of every contract during a hands-on session takes too long, for this tutorial we skip that process and jump directly to the result: the contracts are already signed and available for you to explore.
💡

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.

Step 1: Navigate to Negotiations in the left sidebar. You will see all four negotiations have status SIGNED, meaning both parties completed the full signature process.
TSP Negotiations
TSP InviterTSP RecipientGoalsStatusActions
RenfeLufthansaSingle ticket⊙ SIGNED
RenfeVuelingSingle ticket⊙ SIGNED
RenfeIberiaSingle ticket⊙ SIGNED
Air EuropaRenfeSingle ticket⊙ SIGNED
ℹ️

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.

Step 2: Navigate to Contracts in the left sidebar. This section shows only the Smart Contracts — one per partner TSP. Other contract types (data sharing agreements) exist but are managed separately.
Contracts
Document nameDocument typePeerStatus
SmartContractforSingleTicket.pdfSmart ContractLufthansaSIGNED
SmartContractforSingleTicket.pdfSmart ContractVuelingSIGNED
SmartContractforSingleTicket.pdfSmart ContractIberiaSIGNED
SmartContractforSingleTicket.pdfSmart ContractAir EuropaSIGNED
8

Task 8: Explore the Post-Settlement Dashboard

Review joint ticket sales performance and revenue under a signed contract.
The Post-Settlement dashboard shows aggregated performance data for all joint tickets sold under a contract between two TSPs. The data is fed by the Travel Companion app each time a joint ticket is sold. Since real disruption feeds from TSP endpoints are not yet integrated, disruptions have been simulated to let you explore the full workflow.
Step 1: Click the action icon next to the Lufthansa contract to open it, then click the Dashboard tab.
Step 2: Review the summary metrics for this contract.
618
Tickets sold
170,895 €
Total revenue
90.05%
Tickets with disruptions

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.

9

Task 9: Disruption Management

Explore how the platform automatically handles flight disruptions through smart contract logic.
Below the summary metrics, the Tickets affected by disruptions panel lists each affected ticket with its disruption type, resolution status, and — if resolved — a blockchain transaction hash as immutable proof. When a disruption is registered, the platform checks which tickets are affected and executes the set of actions agreed in the smart contract clauses, sending a proposal to the passenger via the Travel Companion app.
Step 1: Review the disruption list and the different statuses.
Tickets affected by disruptions · 12
30Force majeureACCEPTED
34Force majeureACCEPTED
23DelayACCEPTED
27Force majeureREJECTED
38DelayPENDING
29Force majeureREJECTED
22Force majeureREJECTED
21Force majeureACCEPTED
Disruption detail · ID. 30
Accepted
Force majeure
LHR → FRA
LHR → BCN → FRA
Re-route earliest
Blockchain Registration
Tx hash0x6129c9f6...
NetworkInfura Sepolia
Gas Fee0.004044 ETH
StatusAccepted
Timestamp26/03/2026, 18:26
Step 2: Each ticket can have one of three statuses:
  • 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.
Step 3: Click View on any ACCEPTED ticket to see the full detail panel, including the original route, proposed re-route, final decision, and the complete blockchain registration entry.
Step 4: Click View on a REJECTED ticket and compare. Notice there is no blockchain transaction hash — the entry is only registered on-chain once a final resolution is reached.
Step 5: To understand the logic behind each resolution, open the contract and go to the Clauses and Actions tab. The execution follows this sequence for every disruption:
Disruption detected
Check affected tickets
Notify passengers
Rebooking proposal sent
Resolution on-chain
Smart Contract · Clauses and Actions
UC-NonNominal!-Disruption
ON Event: DisruptionDetected(legA, legB)
IF TicketSold (legA, legB) >= 1
REGISTER Disruption in PlatformDB
NOTIFY Disruption in PlatformDB
UC-NonNominal!-NotifyPassengers
ON Event: DisruptionRegistered(legA, legB)
IF AffectedPassengers (legA, legB) >= 1
FETCH PassengerContactInfo
SEND Notification to Passengers
UC-NonNominal!-RebookingOptions
-- Triggered after passenger response --
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.

10

Task 10: Verify Resolutions on the Blockchain

Inspect the immutable on-chain records of each disruption resolution.
For every disruption resolved by acceptance, SIGN-AIR registers the outcome on the Infura Sepolia testnet blockchain. This provides an immutable, auditable record of every contract execution — including who proposed what, when, and how it was resolved.
Step 1: Open the disruption detail of any ACCEPTED ticket. Scroll down to the Blockchain Registration section and review the following fields:
  • 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.
Step 2: Compare with a REJECTED ticket — there is no blockchain entry. The transaction is only registered once a definitive resolution is reached, keeping the on-chain record clean and meaningful.
🔗

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.

Task 1 / 10