Modular Flight Rights Platform
Budget / Salary₹10,000–15,000
TypeFreelance project
LocationRemote
Posted1 hour ago
The project centres on a green-field, service-oriented “Flight Rights Intelligence Platform”. I need a cleanly separated architecture in which every major domain concern can evolve on its own release cycle yet still work together through well-defined APIs.
Key deliverables
• Flight-data ingestion service able to plug in multiple external providers (REST, SOAP, SFTP or future formats) and let me add or drop a provider with no code change in downstream modules.
• Normalised historical flight database optimised for both point-in-time look-ups and bulk analytics.
• Regulatory rules engine that is fully version-controlled. A ruleset must be timestamped, stored, and traceable so any decision can be reproduced even years later.
• Evidence processing microservice that accepts boarding passes, weather feeds, NOTAMs, etc., and links them to each claim.
• Compensation calculator that applies the active ruleset to the captured evidence to produce a legally sound payout recommendation.
• Claim-outcome tracker to record negotiations, airline responses, paid amounts and final status.
• A decision engine façade that orchestrates the above services and exposes a single, stable endpoint to client apps.
Technical expectations
The stack is open, but the solution has to be container-ready (Docker/Kubernetes), fully documented (OpenAPI for external calls, README for internal repo structure) and CI/CD friendly. Code must be unit-tested and integration-tested; each module should ship with its own test suite.
Acceptance criteria
1. I can register a new flight-data provider through configuration only, restart ingestion, and see the data flow through to the rules engine without touching code.
2. Given a historic flight, the engine can replay the exact regulation version that was active on that date.
3. A claim processed through the API returns a compensation figure together with the rule references and evidence links that justify it.
Bring your preferred languages and frameworks—whether Java/Spring, Node.js, Python/FastAPI or Go—so long as the final solution is modular, testable and ready for production deployment.
Key deliverables
• Flight-data ingestion service able to plug in multiple external providers (REST, SOAP, SFTP or future formats) and let me add or drop a provider with no code change in downstream modules.
• Normalised historical flight database optimised for both point-in-time look-ups and bulk analytics.
• Regulatory rules engine that is fully version-controlled. A ruleset must be timestamped, stored, and traceable so any decision can be reproduced even years later.
• Evidence processing microservice that accepts boarding passes, weather feeds, NOTAMs, etc., and links them to each claim.
• Compensation calculator that applies the active ruleset to the captured evidence to produce a legally sound payout recommendation.
• Claim-outcome tracker to record negotiations, airline responses, paid amounts and final status.
• A decision engine façade that orchestrates the above services and exposes a single, stable endpoint to client apps.
Technical expectations
The stack is open, but the solution has to be container-ready (Docker/Kubernetes), fully documented (OpenAPI for external calls, README for internal repo structure) and CI/CD friendly. Code must be unit-tested and integration-tested; each module should ship with its own test suite.
Acceptance criteria
1. I can register a new flight-data provider through configuration only, restart ingestion, and see the data flow through to the rules engine without touching code.
2. Given a historic flight, the engine can replay the exact regulation version that was active on that date.
3. A claim processed through the API returns a compensation figure together with the rule references and evidence links that justify it.
Bring your preferred languages and frameworks—whether Java/Spring, Node.js, Python/FastAPI or Go—so long as the final solution is modular, testable and ready for production deployment.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.