Aviation safety and training
The engine reads occurrence reports, quality records, training records and flight data monitoring exports into a knowledge base, for safety, quality and training agents. Audit-ready: reporters’ identities are left out.
Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. The reports are not transmitted, and LightHouse does not open the credential.
Read-only, and what is left out
Section titled “Read-only, and what is left out”These connectors never file, change or close anything, so read and write is refused: connect them as Read. By default these are left out:
- reporters’ names;
- everyone’s email addresses, phone numbers and contact details;
- travel document numbers, dates of birth, and health and disability special service requests.
Connect in LightHouse
Section titled “Connect in LightHouse”You need the Client administrator (client_admin) role, signed in as a person, and a deployment whose engine reads this connector (compatibility reference) and keeps credentials in your own store.
- Make the credential at the system, as the section below describes.
- Go to Setup and admin → Connectors, find the system (search for it, or filter by Aviation safety and compliance), and choose Connect.
- Name the fields listed, and leave the access level at Read.
- Paste the credential. Your browser seals it to your deployment; LightHouse never sees it.
- Your deployment keeps it and checks it. The card shows the result.
What the health codes mean
Section titled “What the health codes mean”| Code | The card says | What to do |
|---|---|---|
scope_missing |
The credential signs in, but a scope it carries writes (the scopes are named) | Make a credential with read scopes only, and connect it again |
auth_failed |
The system refused it | It may have expired or been revoked. Make a new one and connect it again |
ECCAIRS 2
Section titled “ECCAIRS 2”- Reads: your organisation’s occurrence reports from EASA’s E2.
- Make: the E2 API client ID and secret EASA issued (client credentials, as EASA’s 2026 change requires). EASA allow-lists your deployment’s address.
- Paste: two lines: the client ID, then its secret.
- Name: E2 sign-in address, only if EASA gave you one; otherwise E2’s own is used.
Ideagen Q-Pulse
Section titled “Ideagen Q-Pulse”- Reads: occurrences with their data fields.
- Make: an integration user of Q-Pulse’s web services, over https.
- Paste: two lines: the integration user, then its password.
- Name: Q-Pulse web services (the https address) and Database. Q-Pulse signs in by a SOAP envelope, so your deployment checks it at the first sync.
Intelex
Section titled “Intelex”- Reads: incidents, audits, findings and actions from the objects you name.
- Make: an integration user and its API key.
- Paste: the API key.
- Name: Your Intelex, the address of your Intelex.
xAPI learning records
Section titled “xAPI learning records”- Reads: training statements from your Learning Record Store (xAPI 1.0.3 or 2.0).
- Make: a read-only key and secret.
- Paste: two lines: the LRS key, then its secret.
- Name: LRS endpoint, your Learning Record Store’s xAPI endpoint.
Flight data monitoring exports
Section titled “Flight data monitoring exports”- Reads: event and exceedance exports from your FDM or FOQA tool, row by row, from a bucket prefix or an SFTP drop.
- No credential is pasted. Your deployment reads the export location your engineer names, as its own identity or a role, so your engineer sets this one up in your source card (In code).
Training exports
Section titled “Training exports”- Reads: training records exported by your LMS, row by row, from a bucket prefix or a drop folder.
- No credential is pasted. As with flight data monitoring exports, your engineer names the export location.
Where the credential is held
Section titled “Where the credential is held”LightHouse never opens these credentials. They are sealed in your browser, or by lighthouse-ai connect <provider> --credential-stdin, to your deployment’s own key, and your deployment keeps them in your own secrets store. LightHouse keeps the connection’s fingerprint, the access level, when it was checked and the check’s code: never the credential, and never what it reads. See Where every credential is held.
Removing it
Section titled “Removing it”On the card, choose Disconnect. Your deployment deletes the credential from your store. Revoke it at the system too. Documents already written stay in the corpus until you delete them.