Solution for Elevator Assessment - Bautista Peco

[bpeco]

This pull request includes my solution for the elevator data modeling assessment.

Summary of decisions:

• Designed a flexible data schema for tracking elevator events and supporting future ML predictions.
• Implemented preprocessing and feature engineering to enrich the raw data with contextual and temporal signals.

How to test:

• README_solution.md has a Usage section: end-to-end usage, including data loading, preprocessing, and model inference.
• Use elevator_model_test.ipynb afterwards to predict.

Please let me know if you have any questions or feedback!

[github-actions]

AI Detection Analysis 🔍

Confidence Score: 30%

Reasoning: The pull request represents a well-structured and comprehensive solution to a technical data science task related to modeling elevator floor predictions. It includes multiple components: data extraction, preprocessing, feature engineering, machine learning training, and model serving. The documentation is clear, with explanations for design decisions, test instructions, and assumptions.

Although the project contains polished language and well-organized modular code — characteristics often associated with AI-generated content — it also exhibits signs of real-world software engineering practices such as progress bars with tqdm, careful handling of rolling time windows, and performance-aware feature encoding. The inclusion of complex, domain-specific logic involving resting floor dynamics and thoughtful preprocessing strategies suggests human domain insight. Furthermore, edge-case awareness (e.g., use of previous floor as a proxy resting state, comments on scalability) points to practical experience unlikely to be fully captured by LLMs without extensive prompting.

There are also slight inconsistencies and human-typical errors:

• Typos like ElevetorModel (instead of ElevatorModel) across multiple files
• Minor redundancy and stylistic variation, e.g., varying detail levels in docstrings
• Imperfect formatting in usage examples (e.g., mix of triple-backticks and markdown bolding)

Key Indicators:

Human Authorship Indicators:

• High-level architectural thinking and choices tailored to domain-specific goals, like temporal train/test splitting and conditional frequency features.
• Commentary and assumptions discussed in README imply field experience and real-world constraints, which are less likely from AI without prompts.
• Typos and naming inconsistencies that AI generators (especially modern ones) generally avoid, e.g., "ElevetorModel" consistently misspelled.
• Use of tqdm and manual loops with rolling windows suggests performance-conscious but unoptimized real-world implementations, typical of human work-in-progress.

Possible AI Indicators:

• Highly polished, structured README with clean markdown
• Modular structure and standard naming conventions
• Some code segments (e.g., compute_features) resemble code that could appear in LLM output, though additive errors (e.g., repetition) deviate from usual AI consistency

Overall, while there are polished components typically seen in AI-assisted outputs, the presence of human-style error patterns, domain-savvy feature decisions, and consistent implementation logic suggests the majority of this contribution is human-generated, perhaps with light AI-assisted help (e.g., Copilot-type suggestions).

Thus, low likelihood of being predominantly AI-generated.

Key Indicators:

• Domain-specific, non-generic feature engineering (conditional frequency given resting floor)
• Typos and naming errors unlikely from modern AI
• Contextual reasoning in design choices and README not typical of generative models without guidance
• Consistency in pipeline logic seen more often in human-driven engineering projects

Overall, more evidence supporting human authorship.

✅ No strong indicators of AI generation detected