Skip to content
The platform

The platform under the operations.

TAM is not a dashboard bolted onto a database. It is a data layer, a connector plane, an AI layer with an evidence trail, and mobile surfaces for the people on the ramp. This page says what each part is and how far it is built.

TAM Core · the unified data layer

One record. Every fact knows where it came from.

The data layer is the product. Applications come and go, integrations change, and the record underneath has to stay true. Three ideas carry it.

Universal data model

One record per person, flight, asset, permit and shift. Each fact is stored once, with its source recorded explicitly, so two systems never argue about whose number is right.

Real time sync engine

Changes flow as events, not as overnight batches. When a permit is approved, the roster sees it. When an employee leaves, access is revoked. Conflicts are surfaced to an administrator, never resolved silently.

Event sourced history

Every change is kept as an event with its provenance. The operation can be replayed for review, which is how a decision survives an audit months later.

Separate data from applications. The layer does not replace the systems the airport already runs. It connects them, records what each system is authoritative for, and fills the gaps where no system exists. Integration first, replacement never.

AeroLink · the universal connector

Connected, not drawn as boxes on a slide.

AeroLink is the integration plane. Inbound, it brings the airport's existing systems into the record. Outbound, it lets the ecosystem around the airport work from the same facts.

Inbound

  • Airport operational database (AODB)
  • A-CDM systems and milestone feeds
  • Access control systems
  • Training and learning management systems
  • HR systems
  • Background check providers

Outbound

  • Webhooks for operational events, from permit issued to flight milestone
  • Event streaming for downstream systems
  • A partner API for the ecosystem around the airport

Credentials for every connection are encrypted at rest, payloads are validated, and each inbound fact keeps the identity of the system it came from.

Honest status. The connector framework, credential handling and validation are built. Vendor specific connectors are built per airport with our design partners, because every estate has its own systems and its own politics. We will tell you which of your systems is connected this quarter, and which is next.

ARIA · AI you can see

Every AI assisted decision carries its evidence.

ARIA is the AI layer of TAM. It reads documents, answers questions over the airport's own procedures, predicts what will expire and what will slip, and takes voice input on the ramp. What it never does is act quietly.

Conversation and knowledge

A conversational assistant over the airport's own procedures and records, in English and Arabic, that cites what it used.

Document intelligence

Classification, text extraction and machine readable zone reading for the documents credentialing and compliance run on.

Prediction

Expiry and risk scoring that turns a compliance backlog into a scheduled queue, so renewals happen before they are late.

Voice operations

Speech in, structured actions out, for hands that are busy with the aircraft rather than a keyboard.

Five levels of supervision

Every AI behaviour sits at one of five proctor levels, set by airport policy and organisational policy. The level decides how much authority the AI holds, and a human can override at every level. Nothing is autonomous by default.

1
Informational
The AI notes what it would do. A human does everything.
2
Suggestion
The AI proposes. A human accepts, edits or ignores.
3
Soft confirm
The AI acts after a single confirmation.
4
Hard confirm
The AI acts only after an explicit, recorded approval.
5
Hard block
The AI may not act. A named human must.

ARIA runs on Kaidera, so the platform rules apply underneath: work classified by impact, high impact actions held for a named human, a transparency panel showing the reasoning and the confidence, and an audit trail of every AI touched decision.

Command Center

The room where the airport runs.

A real time operations picture for the duty team, with control room displays for the wall and for the floor: a handler board, a turnaround monitor and a leaderboard. Broadcast messaging and a daily briefing carry the picture out to everyone else.

Employee mobile

The app that goes onto the ramp.

Two mobile surfaces carry the work to the people who do it. Both install as a progressive web app, so there is no app store between the worker and the shift.

Handler portal

The turnaround workspace for ramp teams: job cards with step by step checklists, digital signature at completion, photo evidence and GPS capture where the operation requires it, and an offline mode that queues every action and syncs when coverage returns. Built to be used in gloves, in weather, between two aircraft.

Staff roster view

The workforce surface: my shifts, my skills, my availability, swap requests and leave, all fed by the same record the planners use. When a permit is renewed in the morning, the evening roster already knows.

Both surfaces are available in English and Arabic, including right to left layout, because the airports we build for are not all in one hemisphere.

Deployment and custody

Sovereign where policy requires it.

TAM Cloud

Managed multi airport operation on distributed SQL, with federation across an operator's estate: one record per airport, one picture for the group. For operators who want the running of the platform to be somebody else's job.

TAM Local

Self hosted inside the operator's own boundary, on PostgreSQL, with offline licence activation for estates whose connectivity or policy cannot assume the cloud. Same product, same record, their custody.

Security posture

Built for a regulated industry. Honest about certificates.

Role based access control down to the individual permission, row level tenancy so one organisation never sees another's record, multi factor authentication, encrypted credentials for every connection, and an append only audit trail of who did what and which AI touched it.

We build to the regulatory requirements of the industry, and the team has delivered under aviation regulation before. Formal certification regimes are on the roadmap. We do not claim a certificate we do not hold, and we will show you the controls themselves instead.

Technical foundation

Boring technology, chosen deliberately.

Portable, self hostable, open where it matters. No managed cloud service that an operator cannot leave.

Services Python with FastAPI, async throughout, one service per domain
Web React with TypeScript, installable as a progressive web app
Data PostgreSQL for a single airport, distributed SQL (YugabyteDB) for federated estates
Events Apache Kafka with change data capture, Redis for hot state
Knowledge Vector search over the airport's own procedures for the AI layer
Runtime Kubernetes with an Envoy gateway, containerised, portable across clouds
AI providers Multi provider by design. The operator's own keys and models can be routed per task.

Bring us your hardest integration.

The ninety day exploration starts with your systems, your silos and your regulators. The honest answer at the end is the point of it.