abhibarman/fde-aviation

Purpose and Entry Points

This is a training challenge repository for investigating a fictional aviation disruption and producing evidence-backed domain, architecture, and intervention proposals. The primary participant workflow begins with the ordered case material in case-study/ and synthetic operational evidence in data/raw/.

A small Python application layer also exists:

• Streamlit UI entry point: streamlit_app.py

• Package/application entry point: aeronexus/main.py

• Package exports: aeronexus/__init__.py

Evidence-First Investigation Boundary

The case-study documents define the business scenario, constraints, stakeholders, event timeline, source systems, and expected deliverables. They are the governing business-evidence layer rather than an implemented production system.

• case-study/00_challenge_brief.md

• case-study/02_incident_timeline.md

• case-study/05_constraints_and_authorities.md

A critical boundary is that conclusions must preserve provenance and contradictions; no individual source is assumed authoritative, and the repository explicitly excludes automation of regulated aviation decisions.

Raw Operational Data Layer

Synthetic, unlabelled source-system extracts supply the material for discovery, reconciliation, and derived findings. The data is file-oriented rather than backed by declared infrastructure or a database.

• Flight and resource records: data/raw/flights.csv, data/raw/gate_resources.csv

• Operational/event feeds: data/raw/disruption_events.jsonl, data/raw/operational_messages.jsonl

• Cross-domain dependencies: data/raw/passenger_connections.csv, data/raw/crew_assignments.csv, data/raw/maintenance_deferrals.csv

Reference definitions in data/reference/data_dictionary.csv provide neutral field/file descriptions, not a preselected target model.

AeroNexus Application Core

The Python package appears to encapsulate the application’s evidence and operational-ontology concerns:

• Evidence handling: aeronexus/evidence.py

• Ontology/domain representation: aeronexus/ontology.py

• Application composition or API-facing behavior: aeronexus/main.py

The intended control flow is raw evidence → provenance-aware evidence interpretation → operational ontology/domain views → interactive or API-consumable presentation. Tests indicate contracts around the application, evidence, and ontology boundaries:

• tests/test_api_contract.py

• tests/test_evidence.py

• tests/test_ontology.py

Interactive Presentation Boundary

streamlit_app.py is the material UI/runtime integration point. It likely consumes the aeronexus package rather than embedding the domain model directly, separating interface concerns from evidence and ontology logic. Streamlit is the only explicitly identifiable runtime/service integration from the repository tree; no cloud platform, database, message broker, or external live aviation service is prescribed.

Participant Delivery Pipeline

The repository structures work as a staged engineering process: discovery and framing, domain modeling, architecture/decision records, application hypothesis, evaluation, and final proposal.

• Instructions: participant-prompts/01_discovery.md, participant-prompts/06_application.md

• Blank deliverable formats: templates/05_bounded_context_canvas.md, templates/10_adr.md, templates/11_traceability.csv

• Output locations/examples: participant-outputs/README.md, participant-outputs/08_final_proposal.md

Traceability is the central cross-cutting requirement: findings and design choices should connect back to raw data and case evidence, while clearly distinguishing facts, derivations, hypotheses, and unresolved questions.

Operational Safety and Scope

The system is an analytical and decision-support training artifact, not an aviation operations authority. It must not determine airworthiness, dispatchability, crew legality, runway clearance, or gate authorization. The architecture therefore requires a deliberate human/authorized-system decision boundary grounded in case-study/05_constraints_and_authorities.md and the challenge rules in README.md.