System Requirements Document for predictive-maintenance-fleet

1. Introduction

This System Requirements Document specifies the deliverable for predictive-maintenance-fleet: a professional, competition-ready PowerPoint submission for Teliport Season 4 — Round 1: Idea Submission. The submission presents the project "Self-Healing Machines: Predictive Maintenance for a Connected Fleet" — an end-to-end system proposal that detects early signs of machine degradation, predicts Remaining Useful Life (RUL), and automatically initiates appropriate maintenance workflows, with human intervention for exceptions.

The product intent is a document deliverable, not a running application: an editable .pptx file produced by editing the uploaded official PowerPoint template directly, preserving its branding and cover slide, and filling the template's blank submission slide with one substantive idea-submission slide. The audience is the Teliport Season 4 judging panel and the submitting team, who must be able to explain and defend every design decision on the slide.

The attached problem statement / case study PDF is the primary source for the idea content; no requirements, results, experiments, performance metrics, or completed functionality may be invented beyond it.

2. System Overview

The current delivery is a two-slide PowerPoint artifact built on the uploaded official template:

1. The preserved cover slide — retained with its original structure, branding, logos, colors, fonts, and layout untouched.
2. One substantive idea-submission slide — the blank submission slide of the template, filled with the idea submission: a left-to-right end-to-end architecture diagram plus compact supporting sections covering the problem and proposed solution, data engineering, machine learning, the rule-based triage agent, MLOps and monitoring, dataset strategy, and the Round 2 roadmap.

The single active human actor is the Competition Team Submitter, who prepares the submission and must be able to defend every design decision. There is no runtime application, no end-user authentication, and no live system: the predictive maintenance system described on the slide is a proposal, and the Round 2 roadmap items are planned implementation steps, not completed functionality.

Provisioned infrastructure (a shared FastAPI backend and a MariaDB database) exists as the application service inventory for the project workspace; it does not add product behavior to this document deliverable and does not justify domain entities, authentication, or an ER model. The deliverable itself is a static file artifact.

Removed from scope

• No running predictive maintenance application, deployed pipeline, or live dashboard is delivered in Round 1.
• No achieved accuracy, benchmark, or performance metric is claimed.
• No additional slides beyond the preserved cover and the one substantive submission slide.
• No replacement theme, imported template, or generic AI-generated presentation design.

2a. Product Interpretation and Delivery Boundary

The requester asked for a finished competition submission, not a software product. The delivery boundary is therefore the editable .pptx file: it must open correctly in Microsoft PowerPoint, export cleanly to PDF, and preserve the official template's identity. All idea content lives on the single submission slide; the cover slide is preserved as-is.

The predictive maintenance system described on the slide — sensor ingestion, validation and preprocessing, rolling-window feature engineering, anomaly detection and RUL prediction, rule-based triage, work-order creation, monitoring and human escalation, MLOps with MLflow, and the FD001-first dataset strategy — is proposed architecture and planned work. It is presented as a design proposal with illustrative thresholds and proposed baseline models, explicitly not as built, deployed, tested, or validated functionality. The Round 2 roadmap is labeled as planned implementation steps.

Access to the deliverable is file-based: the team opens and edits the .pptx locally. No application identity, session, or permission model applies to this deliverable.

2b. Source Content Inventory

The authoritative content source is the attached problem statement / case study PDF (Teliport Season 4, Round 1). The following factual content is carried into the submission slide:

• Project title: Self-Healing Machines: Predictive Maintenance for a Connected Fleet.
• Round: Round 1 — Idea Submission.
• Objective: an end-to-end system that detects early signs of machine degradation, predicts RUL, and automatically initiates appropriate maintenance workflows, with human intervention for exceptions.
• Dataset: NASA C-MAPSS Turbofan Engine Degradation dataset; baseline subset FD001; designed to extend to FD002, FD003, and FD004, which have increasing complexity.
• Architecture chain: Sensor Data / NASA C-MAPSS Dataset → Data Validation and Preprocessing → Rolling-Window Feature Engineering → Anomaly Detection + RUL Prediction → Rule-Based Triage Agent → Maintenance Work Order → Monitoring and Human Escalation for Exceptions.
• Data engineering items: validation of sensor readings and data quality; handling missing values and invalid readings; basic noise treatment; rolling-window features (averages, variability, trends); reproducible preprocessing.
• ML methods: Isolation Forest for anomaly detection; Random Forest Regressor as RUL baseline; evaluation via RUL MAE/RMSE and suitable anomaly metrics where labels permit.
• Triage states: Normal (no sustained risk detected); Warning (low predicted RUL or persistent anomalous behavior); Critical (very low predicted RUL or a validated high-risk condition); Exception (poor data quality, conflicting signals, or uncertain decisions escalated for human review).

• Work order fields: machine identifier, severity, reason, recommended action; plus duplicate prevention and work-order tracking.
• MLOps items: MLflow experiment and model-version tracking; monitoring of data quality, model performance, and prediction drift; controlled retraining workflow; validation of candidate models before promotion; a simple dashboard for machine health, alerts, work orders, and model status.
• Round 2 roadmap (planned): FD001 data pipeline → trained RUL model → anomaly detection → automated work-order workflow → monitoring dashboard → retraining demonstration.

2c. Page Content and Component Coverage

Cover Slide (Preserved)

• Information/state: the template's original cover slide content and structure, unchanged.
• Primary actions: none — this slide is preserved, not authored.
• Supporting actions: none.
• Domain entities: none.
• Component responsibilities: retain original branding, logos, colors, fonts, layout, and editable elements exactly; do not distort, remove, cover, or reposition official logos and branding.
• States: success = cover renders identically to the template original; error = any branding distortion, removal, or repositioning must be corrected before finalizing.

Idea Submission Slide

• Information/state: the single substantive submission slide, containing:
  • Section A — Problem and proposed solution: unexpected machine failures cause downtime and higher maintenance costs; the proposal is a predictive maintenance system that identifies degradation early and initiates maintenance before failure.
  • Section B — End-to-end architecture: the left-to-right chain Sensor Data / NASA C-MAPSS Dataset → Data Validation and Preprocessing → Rolling-Window Feature Engineering → Anomaly Detection + RUL Prediction → Rule-Based Triage Agent → Maintenance Work Order → Monitoring and Human Escalation for Exceptions, with connectors shown and the data-processing pipeline, ML components, decision-making agent, and maintenance action visually distinguished.
  • Section C — Data engineering: validation of sensor readings and data quality; handling missing values and invalid readings; basic noise treatment; rolling-window features (averages, variability, trends); reproducible preprocessing.
  • Section D — Machine learning: Isolation Forest for anomaly detection (unusual sensor patterns); Random Forest Regressor as RUL baseline; explanation that the anomaly detector identifies unusual behavior while the regression model estimates remaining useful life; evaluation via RUL MAE/RMSE and suitable anomaly metrics where labels permit; labeled as proposed choices, not verified best-performing models, with no claimed accuracy.
  • Section E — Rule-based triage agent: decision flow Normal / Warning / Critical / Exception as defined; work order with machine identifier, severity, reason, recommended action; duplicate prevention and work-order tracking; thresholds identified as illustrative and subject to validation.

• Section F — MLOps and monitoring: MLflow experiment and model-version tracking; monitoring of data quality, model performance, and prediction drift; controlled retraining workflow; validation of candidate models before promotion; simple dashboard for machine health, alerts, work orders, and model status.
• Section G — Dataset strategy: NASA C-MAPSS Turbofan Engine Degradation dataset; FD001 baseline; pipeline designed to extend to FD002, FD003, FD004; acknowledged increasing complexity.
• Section H — Round 2 roadmap: FD001 data pipeline → trained RUL model → anomaly detection → automated work-order workflow → monitoring dashboard → retraining demonstration, clearly labeled as planned implementation steps.
• Primary actions: the submitter fills the blank submission slide with the above content, prioritizing the architecture diagram and keeping supporting sections compact.
• Supporting actions: apply clear typography, consistent spacing, readable labels, logical visual hierarchy, simple arrows, restrained icons, and clean diagram elements matching the official template; keep all text within slide boundaries.
• Domain entities: the proposal's conceptual components (dataset, pipeline stages, ML models, triage agent, work orders, monitoring dashboard, model versions) as depicted on the slide — not implemented entities.
• Component responsibilities: architecture diagram is the visual centerpiece; supporting sections are compact and consistent with the diagram; all claims are proposal-only.
• States: success = one substantive slide, readable in presentation mode and PDF export, no overlap or clipping, no invented results; error = text overflow, clipping, overlap, crowded sections, or unsupported claims must be corrected before finalizing.

3. Functional Requirements

FR-1 — Deliver an editable .pptx built on the official template. As a Competition Team Submitter, I should deliver an editable .pptx PowerPoint presentation for Teliport Season 4 — Round 1: Idea Submission, built by editing the uploaded official PowerPoint template file directly, so that the submission is competition-ready and editable. (explicit)

• Trigger/input: uploaded official template file and case study PDF.
• Observable result: an editable .pptx file that opens in Microsoft PowerPoint and exports to PDF.
• Failure/recovery: if the file fails to open or export, correct the file and re-verify before finalizing.
• Continuation: proceed to content verification.

FR-2 — Use the uploaded template as the only template. As a Competition Team Submitter, I should use the uploaded PowerPoint template as the only template — preserving its branding, logos, visual identity, colors, fonts, layout style, and design language — and not replace the theme, import another template, or use a generic AI-generated design, so that template compliance is strict. (explicit)

• Observable result: the deck's visual identity matches the original template.
• Failure/recovery: any deviation is corrected by restoring the original template elements.

FR-3 — Preserve the cover slide and editable elements. As a Competition Team Submitter, I should preserve the existing cover slide and its original structure and retain the original template's editable elements wherever possible, so that the template's identity is intact. (explicit)

• Observable result: cover slide unchanged; editable elements retained.

FR-4 — Protect official logos and branding. As a Competition Team Submitter, I should not distort, remove, cover, or reposition official logos and branding, so that branding integrity is preserved. (explicit)

• Observable result: logos and branding appear exactly as in the template.

FR-5 — Fill the blank submission slide with one substantive submission. As a Competition Team Submitter, I should fill the template's blank submission slide with the actual idea submission, using one substantive submission slide as required by the event's 1-slide rule, and add slides only if explicitly required by the template or event instructions, so that the deliverable is the preserved cover plus exactly one substantive submission slide. (explicit)

• Observable result: exactly two slides — preserved cover and one substantive submission slide.
• Failure/recovery: remove any extra slides not explicitly required.

FR-6 — State the project title and round. As a Competition Team Submitter, I should present the project title "Self-Healing Machines: Predictive Maintenance for a Connected Fleet" and the round "Round 1 — Idea Submission" on the submission. (explicit)

FR-7 — State the objective. As a Competition Team Submitter, I should state the objective: propose an end-to-end system that detects early signs of machine degradation, predicts RUL, and automatically initiates appropriate maintenance workflows, with human intervention for exceptions. (explicit)

FR-8 — Section A: problem and proposed solution. As a Competition Team Submitter, I should briefly explain that unexpected machine failures cause downtime and higher maintenance costs and propose a predictive maintenance system that identifies degradation early and initiates maintenance before failure occurs. (explicit)

FR-9 — Section B: end-to-end architecture. As a Competition Team Submitter, I should present a clear left-to-right workflow — Sensor Data / NASA C-MAPSS Dataset → Data Validation and Preprocessing → Rolling-Window Feature Engineering → Anomaly Detection + RUL Prediction → Rule-Based Triage Agent → Maintenance Work Order → Monitoring and Human Escalation for Exceptions — showing how components connect and clearly distinguishing the data-processing pipeline, ML components, decision-making agent, and maintenance action. (explicit)

FR-10 — Section C: data engineering. As a Competition Team Submitter, I should cover validation of sensor readings and data quality, handling missing values and invalid readings, basic noise treatment, rolling-window features such as averages, variability, and trends, and reproducible preprocessing. (explicit)

FR-11 — Section D: machine learning approach. As a Competition Team Submitter, I should propose Isolation Forest for anomaly detection to identify unusual sensor patterns and Random Forest Regressor as a baseline for estimating RUL; explain that the anomaly detector identifies unusual behavior while the regression model estimates remaining useful life; mention evaluation using RUL MAE/RMSE and suitable anomaly metrics where labels permit; and present these as proposed choices, not verified best-performing models, with no claimed achieved accuracy or performance. (explicit)

FR-12 — Section E: rule-based triage agent. As a Competition Team Submitter, I should show a concise decision flow — Normal (no sustained risk detected), Warning (low predicted RUL or persistent anomalous behavior), Critical (very low predicted RUL or a validated high-risk condition), Exception (poor data quality, conflicting signals, or uncertain decisions escalated for human review) — and show that the agent creates a maintenance work order with machine identifier, severity, reason, and recommended action, including duplicate prevention and work-order tracking; any thresholds must be identified as illustrative and subject to validation, not established facts. (explicit)

FR-13 — Section F: MLOps and monitoring. As a Competition Team Submitter, I should briefly show experiment and model-version tracking with MLflow, monitoring of data quality, model performance, and prediction drift, a controlled retraining workflow when new data becomes available, validation of candidate models before promotion, and a simple dashboard for machine health, alerts, work orders, and model status. (explicit)

FR-14 — Section G: dataset strategy. As a Competition Team Submitter, I should use the NASA C-MAPSS Turbofan Engine Degradation dataset specified in the case study, start with FD001 as the baseline subset, design the pipeline to extend to FD002, FD003, and FD004, and acknowledge that the subsets have increasing complexity. (explicit)

FR-15 — Section H: Round 2 roadmap. As a Competition Team Submitter, I should conclude with a concise planned progression — FD001 data pipeline → trained RUL model → anomaly detection → automated work-order workflow → monitoring dashboard → retraining demonstration — clearly labeled as planned implementation steps. (explicit)

FR-16 — Design quality. As a Competition Team Submitter, I should design the slide as a polished engineering proposal rather than a text-heavy report: prioritize the architecture diagram, use compact supporting sections, clear typography, consistent spacing, readable labels, logical visual hierarchy, simple arrows, restrained icons, and clean diagram elements matching the official template. (explicit)

FR-17 — Readability and boundaries. As a Competition Team Submitter, I should avoid excessive text, decorative graphics, unnecessary gradients, oversized headings, and crowded sections; ensure readability in presentation mode and PDF export; and keep all text within slide boundaries. (explicit)

FR-18 — Technical precision and consistency. As a Competition Team Submitter, I should use precise technical language and maintain consistency across the architecture, model choices, agent logic, and roadmap. (explicit)

FR-19 — Content integrity. As a Competition Team Submitter, I should not claim the system has already been built, deployed, tested, or validated, and should not fabricate results, benchmarks, datasets, citations, team details, or credentials. (explicit)

FR-20 — Scope integrity. As a Competition Team Submitter, I should not add technologies that conflict with the proposed architecture, not change the problem statement or introduce unrelated features, and keep the submission understandable enough for the team to explain and defend every design decision. (explicit)

FR-21 — Pre-finalization verification. As a Competition Team Submitter, I should verify before finalizing: original template and branding preserved; only one substantive idea-submission slide; all Round 1 deliverables from the case study addressed; architecture clear and internally consistent; no text overlaps, clipping, or unreadable content; no invented results or unsupported claims; file opens correctly in Microsoft PowerPoint and can be exported to PDF. (explicit)

FR-22 — Priority ordering. As a Competition Team Submitter, I should prioritize strict template compliance, technical clarity, architecture quality, and completeness of the Round 1 idea submission when trade-offs arise. (explicit)

4. User Personas

Competition Team Submitter

• Product context: A member of the team entering Teliport Season 4, Round 1. They have the attached problem statement / case study PDF and the uploaded official PowerPoint template, and must produce the idea submission by editing the template directly.
• Primary goal: Deliver a competition-ready, editable .pptx that preserves the official template's branding and cover slide, contains exactly one substantive submission slide, and presents the predictive maintenance proposal with technical clarity and no invented results.
• Distinct accepted responsibilities: Fill the blank submission slide with sections A–H; prioritize the architecture diagram; keep supporting sections compact; label proposed models and illustrative thresholds honestly; label the Round 2 roadmap as planned; verify template preservation, slide count, readability, and content integrity before finalizing.
• Relevant inputs or decisions: The case study PDF (primary source), the official template file, the choice of how to lay out the left-to-right architecture and supporting sections within one slide, and the decision to present all ML choices as proposals rather than results.
• Interactions with other accepted participants: None beyond the team itself; the persona must be able to explain and defend every design decision to the judging panel.
• Observable success: The .pptx opens in Microsoft PowerPoint, exports to PDF, preserves the template and cover slide, has exactly one substantive submission slide, addresses all Round 1 deliverables, and contains no fabricated results or unsupported claims.

5. Core User Flows

Flow 1 — Prepare the submission from the official template

1. The Competition Team Submitter opens the uploaded official PowerPoint template file directly in PowerPoint.
2. The submitter confirms the cover slide is preserved with its original structure, branding, logos, colors, fonts, and layout.
3. The submitter locates the template's blank submission slide.
4. The submitter confirms no additional slides are required by the template or event instructions (the event requires a 1-slide idea submission).
5. Result: the working file is the official template with its cover preserved and one blank submission slide ready to fill.
6. Failure/recovery: if the template cannot be opened or branding appears altered, restore the original file and reopen before editing.

Flow 2 — Compose the single idea-submission slide

1. Starting from the blank submission slide, the submitter adds the project title "Self-Healing Machines: Predictive Maintenance for a Connected Fleet" and the round "Round 1 — Idea Submission."
2. The submitter writes Section A: unexpected machine failures cause downtime and higher maintenance costs; the proposal is a predictive maintenance system that identifies degradation early and initiates maintenance before failure.
3. The submitter builds Section B as the visual centerpiece: the left-to-right chain Sensor Data / NASA C-MAPSS Dataset → Data Validation and Preprocessing → Rolling-Window Feature Engineering → Anomaly Detection + RUL Prediction → Rule-Based Triage Agent → Maintenance Work Order → Monitoring and Human Escalation for Exceptions, with connectors and visual distinction between data-processing pipeline, ML components, decision-making agent, and maintenance action.
4. The submitter adds compact Section C (data engineering: validation, missing/invalid handling, noise treatment, rolling-window averages/variability/trends, reproducible preprocessing).
5. The submitter adds compact Section D (Isolation Forest for anomaly detection; Random Forest Regressor as RUL baseline; anomaly detector identifies unusual behavior while regression estimates RUL; evaluation via RUL MAE/RMSE and anomaly metrics where labels permit; labeled as proposed choices with no claimed accuracy).
6. The submitter adds compact Section E (Normal / Warning / Critical / Exception decision flow; work order with machine identifier, severity, reason, recommended action; duplicate prevention and work-order tracking; thresholds labeled illustrative and subject to validation).

7. The submitter adds compact Section F (MLflow tracking; monitoring of data quality, model performance, prediction drift; controlled retraining; candidate validation before promotion; simple dashboard for machine health, alerts, work orders, model status).
8. The submitter adds compact Section G (NASA C-MAPSS Turbofan Engine Degradation dataset; FD001 baseline; extendable to FD002, FD003, FD004; increasing complexity acknowledged).
9. The submitter concludes with Section H, the Round 2 roadmap labeled as planned: FD001 data pipeline → trained RUL model → anomaly detection → automated work-order workflow → monitoring dashboard → retraining demonstration.
10. Result: one substantive submission slide with a coherent architecture diagram and compact supporting sections.
11. Failure/recovery: if sections crowd the slide or text overflows, reduce text, tighten spacing, and re-prioritize the architecture diagram per the stated priority.
12. Continuation: proceed to verification.

Flow 3 — Verify and finalize the deliverable

1. The submitter checks the original template and branding are preserved and the cover slide is unchanged.
2. The submitter confirms there is only one substantive idea-submission slide.
3. The submitter confirms all Round 1 deliverables from the case study are addressed.
4. The submitter confirms the architecture is clear and internally consistent with the model choices, agent logic, and roadmap.
5. The submitter checks for text overlap, clipping, or unreadable content in presentation mode and PDF export.
6. The submitter confirms no invented results or unsupported claims appear.
7. The submitter opens the file in Microsoft PowerPoint and exports to PDF to confirm both succeed.
8. Result: the finalized editable .pptx is delivered.
9. Failure/recovery: any failed check is corrected and the verification repeated before delivery.

6. Visuals Colors and Theme

The authoritative visual source is the uploaded official PowerPoint template. Its branding, logos, visual identity, colors, fonts, layout style, and overall design language are preserved exactly; no new theme, palette, or font family is introduced. The following are binding presentation rules rather than a new design system:

• Color: inherit the template's palette; do not introduce gradients or decorative color treatments beyond the template's own design language.
• Typography: inherit the template's fonts; use clear typography, consistent spacing, readable labels, and logical visual hierarchy.
• Diagram elements: simple arrows, restrained icons, and clean diagram elements that match the official template.
• Restraint: avoid excessive text, decorative graphics, unnecessary gradients, oversized headings, and crowded sections.
• Readability: ensure the slide is readable in presentation mode and when exported to PDF, with all text within slide boundaries.

[Default — not specified by user] Any specific hex values, type scale, or spacing tokens beyond the template's own are not specified; the template governs.

7. Signature Design Concept

The signature visual idea is the left-to-right architecture spine as the dominant element of the single submission slide: a horizontal chain of connected stages — Sensor Data / NASA C-MAPSS Dataset → Data Validation and Preprocessing → Rolling-Window Feature Engineering → Anomaly Detection + RUL Prediction → Rule-Based Triage Agent → Maintenance Work Order → Monitoring and Human Escalation for Exceptions — rendered with simple arrows and restrained icons in the template's own visual language, with the data-processing pipeline, ML components, decision-making agent, and maintenance action visually distinguished (for example by grouping or labeling). Compact supporting sections (A, C, D, E, F, G, H) sit around the spine without crowding it, so the architecture reads first and the supporting detail reads second. This concept only recomposes the accepted content and controls; it adds no new behavior or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: still Hero Dimensionality: flat

The deliverable is a static PowerPoint slide deck; the template's design language governs and no motion is specified. The "hero" is the architecture spine on the submission slide.

Landing Hero Motion Brief: Not applicable — the deliverable is a static .pptx file with no animated entry surface. The composed first frame is the submission slide as it appears in presentation mode: the architecture spine across the slide with compact supporting sections. Reduced-motion state: identical, since no motion exists.

9. Non-Functional Requirements

• Template fidelity (explicit): the uploaded template is the only template; branding, logos, visual identity, colors, fonts, layout style, and design language are preserved; the cover slide and its original structure are preserved; official logos and branding are not distorted, removed, covered, or repositioned.
• Slide count (explicit): exactly the preserved cover slide plus one substantive idea-submission slide; additional slides only if explicitly required by the template or event instructions.
• Editability (explicit): the deliverable is an editable .pptx; original editable elements are retained wherever possible.
• Compatibility (explicit): the file opens correctly in Microsoft PowerPoint and can be exported to PDF.
• Readability (explicit): readable in presentation mode and PDF export; no text overlaps, clipping, or unreadable content; all text within slide boundaries.
• Content integrity (explicit): no claims that the system is built, deployed, tested, or validated; no fabricated results, benchmarks, datasets, citations, team details, or credentials; proposed models and illustrative thresholds are labeled as such; Round 2 items are labeled planned.
• Technical consistency (explicit): precise technical language; consistency across architecture, model choices, agent logic, and roadmap.
• Defensibility (explicit): the submission must be understandable enough for the team to explain and defend every design decision.

10. Tech Stack

• Deliverable format: editable .pptx PowerPoint file, built by editing the uploaded official template directly. (explicit)
• Proposed system components named on the slide (proposal only, not implemented): NASA C-MAPSS Turbofan Engine Degradation dataset (FD001 baseline; FD002–FD004 extension); Isolation Forest; Random Forest Regressor; MLflow for experiment and model-version tracking; a simple monitoring dashboard for machine health, alerts, work orders, and model status. (explicit)
• Provisioned application services (inventory): a shared FastAPI backend process for application APIs and domain modules, and a MariaDB database for application-owned persistent data. These are the provisioned infrastructure inventory and do not add product behavior to this document deliverable. (basic_default)

11. Assumptions and Constraints

• Assumption: the uploaded official PowerPoint template file is available as the base file. (required_inference)
• Assumption: the attached problem statement / case study PDF is available as the primary content source. (required_inference)
• Constraint: the uploaded template is the only template; no theme replacement, template import, or generic AI-generated design. (explicit)
• Constraint: the existing PowerPoint file is edited directly; editable elements are retained wherever possible. (explicit)
• Constraint: the cover slide and its original structure are preserved. (explicit)
• Constraint: official logos and branding are not distorted, removed, covered, or repositioned. (explicit)
• Constraint: one substantive submission slide; additional slides only if explicitly required by the template or event instructions. (explicit)
• Constraint: the case study is the primary source; no invented requirements, results, experiments, performance metrics, or completed functionality. (explicit)
• Constraint: no claims of built, deployed, tested, or validated status; no fabricated results, benchmarks, datasets, citations, team details, or credentials. (explicit)
• Constraint: no technologies that conflict with the proposed architecture; no changes to the problem statement or unrelated features. (explicit)
• Constraint: Isolation Forest and Random Forest Regressor are proposed choices, not verified best-performing models; no achieved accuracy or performance is claimed. (explicit)
• Constraint: triage thresholds are illustrative and subject to validation, not established facts. (explicit)

• Constraint: Round 2 roadmap items are clearly labeled as planned implementation steps. (explicit)
• Constraint: all text stays within slide boundaries; no overlap, clipping, or unreadable content. (explicit)
• Constraint: the deliverable is an editable .pptx using the uploaded official template as the base file. (explicit)
• Constraint: the deliverable is the preserved cover slide plus exactly one substantive submission slide. (explicit)
• Priority: strict template compliance, technical clarity, architecture quality, and completeness of the Round 1 idea submission. (explicit)

12. Glossary

• Teliport Season 4 — Round 1: Idea Submission: the competition round for which this submission is prepared.
• RUL (Remaining Useful Life): the estimated remaining operating life of a machine before failure.
• NASA C-MAPSS: the Turbofan Engine Degradation dataset specified in the case study; subsets FD001 (baseline), FD002, FD003, FD004, with increasing complexity.
• Isolation Forest: the proposed anomaly-detection method for identifying unusual sensor patterns.
• Random Forest Regressor: the proposed baseline regression method for estimating RUL.
• Rule-Based Triage Agent: the decision component that classifies machine state as Normal, Warning, Critical, or Exception and creates maintenance work orders.
• Work Order: a maintenance record containing machine identifier, severity, reason, and recommended action, with duplicate prevention and tracking.
• MLflow: the proposed tool for experiment and model-version tracking.
• Prediction Drift: change in model prediction behavior monitored over time.
• Round 2 Roadmap: the planned implementation progression labeled as planned steps, not completed work.