AI Skill Report Card
Designing Building Engineering Research
Quick Start14 / 15
Given a raw research topic like:
"Обоснование алгоритмов работы умных систем отопления... с применением методов конечно-элементного анализа"
Immediately decompose it into the standard research skeleton:
- Problem statement — what engineering deficiency or inefficiency motivates this work
- Object & subject of research — object = the system (e.g., smart HVAC control system); subject = the specific aspect studied (e.g., control algorithms)
- Method justification — why this method (FEA, math modeling, comparative analysis) fits the object, not just a generic method description
- Constraints — real environment conditions (climate, hardware limits, regulatory norms) that shape the method's application
- Expected result / criteria of evaluation — measurable outcome (energy savings %, deviation from standard, computational cost)
Output a structured one-page research framing before any literature review or calculations begin.
Recommendation▾
Translate the Russian examples/quotes into English or provide bilingual glosses so the skill is fully usable by non-Russian-speaking instances without context loss.
Workflow14 / 15
Progress:
- Step 1: Clarify object vs. subject of research (do not conflate system with parameter)
- Step 2: Identify the core engineering contradiction (e.g., comfort vs. energy cost; accuracy vs. compute budget)
- Step 3: Select and justify method(s) — tie each method directly to the contradiction, not generically
- Step 4: List environmental/operational constraints that modify standard method application
- Step 5: Define evaluation criteria and expected quantifiable result
- Step 6: Draft comparative baseline (existing solutions/normatives) against which the proposed approach will be measured
- Step 7: Flag data/resource requirements (sensors, telemetry, soil data, computational power)
Step 1–2 details
Separate "what is being improved" (object) from "what is being measured/changed" (subject). Example: object = ventilation system of an office building; subject = acoustic comfort parameters derived from real-time telemetry.
Step 3 details
Match method to problem type:
- FEA → thermal/structural/airflow distribution problems with spatial geometry dependence
- Comparative technology analysis → when multiple existing solutions must be ranked under a resource constraint
- Mathematical/optimization modeling → when the goal is minimizing/maximizing a function (collision count, cost, clash count) under constraints
- Statistical/telemetry-based modeling → when parameters must be derived empirically from continuous sensor data rather than normative tables
Step 4 details
Always ask: does geography, climate, legacy infrastructure, or regulation change the "textbook" application of the method?
- Permafrost → soil behavior models must account for seasonal thaw/freeze cycles and anthropogenic heat sources (buildings, pipelines)
- Limited computational resources → recycling technology comparison must weight algorithmic complexity, not only effectiveness
- Open office space → acoustic standards (ISO 3382-3) must be adapted using live occupancy/telemetry rather than static assumptions
Recommendation▾
Add a 'bad output' example (e.g., a poorly conflated object/subject) alongside good ones to sharpen contrast per best-practice grading.
Examples17 / 20
Example 1: Input: "Обоснование алгоритмов работы умных систем отопления, вентиляции и кондиционирования (HVAC) с применением методов конечно-элементного анализа." Output:
- Object: smart HVAC control system in a building
- Subject: control algorithm logic (setpoint adaptation, zoning)
- Contradiction: energy efficiency vs. thermal comfort under variable occupancy
- Method justification: FEA used to simulate heat/air distribution per zone, validating algorithm decisions against physical airflow/thermal models rather than simplified lumped-parameter models
- Constraints: building envelope properties, occupancy patterns, sensor placement limits
- Evaluation criteria: reduction in energy consumption (%) at constant or improved PMV/PPD comfort index
- Baseline: compare against rule-based (non-adaptive) HVAC control
Example 2: Input: "Сравнительный анализ технологий рециклинга строительных отходов в условиях ограниченных вычислительных ресурсов." Output:
- Object: construction waste recycling technology options
- Subject: comparative efficiency under constrained compute (e.g., sorting/classification algorithms on edge devices)
- Contradiction: recycling accuracy/throughput vs. available processing power
- Method justification: comparative multi-criteria analysis (AHP or weighted scoring) using complexity/accuracy/energy-cost metrics instead of cloud-scale ML benchmarks
- Constraints: embedded hardware specs, dataset size, real-time sorting speed requirements
- Evaluation criteria: classification accuracy per watt / per FLOP, cost-per-ton processed
- Baseline: manual sorting vs. existing full-scale automated sorting lines
Example 3: Input: "Исследование влияния подземных вод на фундаменты зданий в условиях вечной мерзлоты с учетом антропогенного фактора." Output:
- Object: building foundations in permafrost zones
- Subject: groundwater influence combined with anthropogenic heat impact
- Contradiction: structural stability norms (designed for stable permafrost) vs. actual thaw dynamics induced by heated structures
- Method justification: coupled thermal-hydrological modeling (can reference FEA for heat transfer) plus field monitoring data
- Constraints: seasonal variability, building heat leakage, drainage infrastructure
- Evaluation criteria: predicted thaw depth deviation, foundation settlement risk index
- Baseline: compare against SNiP/SP permafrost foundation design norms
Recommendation▾
Trim slight redundancy between 'Workflow Step details' and 'Best Practices'/'Common Pitfalls' sections, which restate similar points about object/subject and constraints.
Best Practices
- Always force a clear object/subject split before writing anything else — this is the most common structural defect in such research proposals.
- Name the contradiction explicitly (tradeoff that justifies why research is needed) — a topic without a tradeoff is not yet a research question.
- Justify method choice by mapping method capability to problem geometry/data type, not by popularity of the method.
- Always state what existing norm, standard, or baseline solution is being improved upon or compared against.
- Make evaluation criteria quantifiable (%, index, cost units) — avoid vague "improve efficiency" framings.
- When telemetry/real-time data is involved, specify sampling rate, sensor type, and data volume — these determine feasible methods.
- For constrained-resource topics (compute, remote geography), treat the constraint as a first-class design variable, not a footnote.
Common Pitfalls
- Treating method (FEA, BIM, math modeling) as a buzzword attached to the topic rather than justifying its fit to the specific physical/data problem.
- Conflating the system (HVAC, foundation, office space) with the parameter being measured (algorithm, comfort index, groundwater level) — leads to unfocused scope.
- Ignoring environmental/regulatory context (permafrost codes, ISO acoustic standards, local waste regulations) that any real engineering justification must reference.
- Proposing comparative analysis without defining weighting criteria — "comparison" without explicit multi-criteria weights is not rigorous.
- Setting evaluation criteria that can't actually be measured with available data/instrumentation (e.g., promising real-time comfort tracking without specifying sensors).
- Omitting the resource constraint from the method itself (e.g., discussing ML-based waste sorting without addressing it actually running within the stated limited compute budget).