RIFFHELM AI PREPARATION PROMPT — V7 FINAL GENERIC
Mandatory Multi-Pass Reconciliation + Unresolved Rescue + Legacy/Supersession + Duplicate Prevention + Customer Approval Gate

You are preparing maintenance data for import into Riffhelm.

I will provide you with:

1. The official Riffhelm Import Template (.xlsx).
2. One or more existing maintenance files containing my current maintenance data.

Your job is to consolidate, clean, normalize, and transfer the relevant maintenance data from my existing files into the official Riffhelm template.

IMPORTANT WORKING METHOD:

First analyze ALL files and complete everything you can reliably complete without asking me unnecessary questions.

Do not stop after every uncertainty.

If clarification is genuinely required, collect all important unresolved questions and ask me ONE short consolidated set of questions.

Only ask questions where my answer is genuinely required to create a reliable result.

For straightforward mappings, normalization, obvious conversions, and high-confidence decisions, proceed automatically.

After I answer the consolidated clarification questions, complete the file.

CRITICAL TEMPLATE RULE:

The Riffhelm template is the target contract.

Do NOT redesign it.
Do NOT rename columns.
Do NOT reorder columns.
Do NOT add columns.
Do NOT remove columns.
Do NOT change the workbook structure.

Fill the existing Import Template sheet only and preserve the other Riffhelm sheets.

The final file must remain an .xlsx file that can be uploaded directly into Riffhelm.

OFFICIAL RIFFHELM COLUMNS:

- Department
- Asset / Machine
- Task Description
- Task Type
- Trade
- Frequency
- Estimated Minutes
- Required Parts
- Instructions / Notes

Each row must represent one real recurring maintenance task or operator check.

DATA CONSOLIDATION:

Review ALL files I provide.

The same department, machine, maintenance plan, task, checklist, operation, or instruction may appear in different files, sheets, languages, or formats.

Consolidate the information intelligently.

Do not simply append sheets without understanding their structure.

Identify:
- Departments
- Assets / Machines
- Maintenance plans / parent routines
- Concrete maintenance tasks / operations
- Instructions or explanatory detail
- Task type
- Trade / profession
- Maintenance frequency
- Estimated duration
- Required parts
- Instructions or notes

Preserve useful maintenance information from the original files.

==================================================
GENERICITY RULE — WORK FOR ANY FACTORY
==================================================

This prompt must work for any industrial site, company, country, language, maintenance system, and equipment population.

Do NOT assume:
- any specific company or plant;
- any specific department names;
- any specific equipment names or asset codes;
- any specific ERP / CMMS vendor;
- any specific trade names beyond what the source supports;
- any specific industry;
- any specific language;
- any specific file naming convention.

All Department, Asset / Machine, Trade, Frequency, task, hierarchy, alias, and legacy/supersession decisions must be derived from the supplied files and the official Riffhelm template.

Examples in this prompt are illustrative only. They are never hard-coded mappings.

FULL WORKBOOK STRUCTURE SCAN — MANDATORY:

Do not assume that the important fields are located only in the first visible columns or in the main data table.

For EVERY workbook:
- inspect EVERY worksheet;
- inspect the FULL used range of each worksheet, including far-right columns;
- inspect sparse/auxiliary classification columns;
- inspect hidden or visually secondary columns when accessible;
- inspect merged cells, section headers, repeated headers, block labels, subtotal rows and continuation rows;
- do not ignore a column merely because most of its cells are blank.

DEPARTMENT / AREA DISCOVERY:

Department information may be stored in any of these forms:
- a normal Department column repeated on every row;
- a department value shown only once at the beginning of a machine/task block;
- a far-right auxiliary/classification column;
- a section heading or merged cell;
- a separate worksheet that maps equipment to departments;
- an equipment/classification table that must be joined to the maintenance-plan table.

When a department marker appears once at the start of a logical block and subsequent rows are blank in that department field:
1. Treat the marker as applying to the following rows in the SAME logical block.
2. Continue the department until the next explicit department marker.
3. STOP propagation at a new table/header, subtotal, Grand Total, unrelated section, or another clear structural boundary.
4. Do not propagate a department through unrelated blank areas.
5. Preserve the exact plant department terminology from the source.

Before finalizing the output, build an internal inventory of ALL explicit department/area labels found anywhere in the supplied workbooks and verify that each one is either:
- represented by mapped equipment/tasks in the final output, or
- explicitly listed in the final summary as discovered but not safely assignable.

If two sources give different department labels for the same asset:
- prefer an explicit equipment-to-department mapping over filename inference;
- prefer a direct row/block classification over a guess from task text;
- do not silently collapse a more granular department into a broader department, or vice versa, when both are explicit;
- if the difference could materially change the plant structure, include ONE concise clarification question in the consolidated clarification round.

CONTINUATION ROWS:

ERP exports may repeat an asset code/name only on the first row and leave it blank on subsequent treatment rows.
When the structure is clear, inherit the Asset / Machine and Department from the nearest preceding explicit row ONLY inside the same logical block.
Do not carry values across a new section, header, subtotal, Grand Total, or unrelated block.

SOURCE HIERARCHY, GROUPED TREATMENTS, AND PLAN / TASK / INSTRUCTION LOGIC:

Maintenance exports may contain several representations of the same maintenance work. You must distinguish between them before creating rows.

A. PLAN / HEADER
A plan/header is a recurring parent treatment such as:
- "Monthly maintenance - Machine X"
- "Quarterly treatment"
- an ERP preventive-maintenance plan code
- a recurring routine title that has child operations underneath it

B. CONCRETE ACTION / CHECKLIST ITEM
A concrete action is an actionable step inside a treatment, such as:
- Check oil level
- Lubricate bearings
- Clean electrical cabinet
- Replace filter

C. INSTRUCTION / DETAIL
An instruction/detail explains HOW to perform an action but is not necessarily an independently scheduled recurring task.

Examples:
- safety instruction
- procedure detail
- a continuation line
- a part number or parameter
- "perform the daily routine" inside a monthly/quarterly plan

GROUPED TREATMENTS ARE REQUIRED:

Riffhelm supports grouped/consolidated treatments. When several actions belong to the SAME maintenance visit, return ONE parent task row with the individual actions preserved as a checklist in Instructions / Notes.

A high-confidence grouped-treatment candidate requires the same:
- Department
- Asset / Machine
- Trade
- Frequency
- Task Type (Preventive Maintenance or Operator Check)
- compatible maintenance scope / same visit

Do NOT group:
- Mechanic PM with Electrician PM
- Preventive Maintenance with Operator Check
- different frequencies
- different equipment
- actions that are clearly independent maintenance visits

For a grouped treatment:
1. Create ONE clear parent Task Description, preferably using an explicit source plan/title when available. Otherwise create a concise treatment title such as "Monthly Preventive Maintenance" or an equivalent plant-language title.
2. Put every real child action on its own line in Instructions / Notes using the exact bullet format:
   • action 1
   • action 2
   • action 3
3. Preserve useful non-action notes separately as normal non-bulleted text.
4. Keep at least TWO real actionable bullet lines before treating the row as a grouped/checklist treatment.
5. Do NOT create the child actions again as separate PM/AM rows when they are only checklist actions inside the grouped treatment.
6. Do NOT lose any action merely because it was grouped.
7. Grouping is NOT duplicate deletion. If two actions may be true duplicates, handle that as a separate duplicate decision.

This bullet format is intentional: Riffhelm's canonical template importer recognizes multiple actionable bullet lines in Instructions / Notes and converts them into the task checklist.

RULES:

1. Do NOT automatically create a Riffhelm task row for every line in an ERP export.

2. If a parent plan has clearly linked child actions, preserve the PARENT treatment and return the child actions as its checklist. Do NOT flatten the parent away and do NOT explode each child action into a separate recurring task unless the source proves that the actions are independently scheduled.

3. If a parent plan is the only reliable recurring record and its child/detail rows cannot be safely linked to that recurrence, preserve the parent plan as the canonical recurring task. Do NOT invent recurrence for unlinked child rows.

4. If an instruction line only explains or expands a checklist action, preserve it with that action or as non-bulleted Instructions / Notes instead of creating another recurring task.

5. A reference such as "perform daily instructions" inside a quarterly/monthly routine is a dependency/reference. It does NOT mean the daily tasks should be recreated at the quarterly/monthly frequency.

6. If both a detailed machine-specific maintenance file and a summary ERP / CMMS / legacy system plan cover the same machine and maintenance visit, use the explicit recurring plan/title as the parent when it is reliably matched, and use the detailed source to build/enrich the checklist, trade, duration, parts and notes. Do not create a duplicate parent from both sources.

7. Source preference for facts when sources overlap:
   a. Explicit machine-specific values for trade/duration/parts/action detail
   b. Explicit recurring ERP / CMMS / legacy system plan for parent identity/frequency when reliably linked
   c. Clearly linked ERP operation/task record
   d. Free-text instruction/comment

Use sources together to create one canonical grouped treatment rather than duplicating representations.

8. If several machine-specific actions share Department + Asset + Trade + Frequency + Task Type and clearly represent one visit, group them even when no explicit parent title exists. Preserve every action as a bullet checklist item.

9. If the file structure does not provide enough evidence to decide whether lines belong to one visit or several independent treatments, ask ONE consolidated clarification question rather than making a structural guess.

ASSET / MACHINE IDENTITY AND ALIASES:

The same machine may appear under slightly different names in different files.

Use the following evidence in order:

1. Exact equipment / asset code match, when present.
2. Exact machine name match.
3. Strong contextual match: same department, highly similar machine name, matching task set, matching plan context.

If two names are clearly aliases for the same asset, consolidate them into one asset and use the clearest / richest plant name from the most detailed source.

Do NOT merge assets only because the names look similar.

If names conflict materially or the identity is uncertain, include ONE question in the consolidated clarification round.

DUPLICATES:

Detect obvious duplicate maintenance tasks across ALL files and sheets.

If the same real task appears several times for the same machine with the same frequency and is clearly a duplicate, consolidate it into one row.

Prefer the row/source with richer information and merge useful non-conflicting details such as parts, duration and notes.

Do NOT merge tasks merely because their descriptions look similar.

When uncertain whether two records are duplicates, preserve both or ask me in the consolidated clarification round.

TASK TYPE:

The only valid Task Type values are:
- Preventive Maintenance
- Operator Check

Use explicit source information whenever available.

If the source does not explicitly state the Task Type, infer it from the task context when reasonably clear.

Routine inspections, visual checks, simple cleaning, readings, and basic operator activities may normally be classified as Operator Check when the source/context indicates operator ownership.

Maintenance activities performed by maintenance personnel should normally be classified as Preventive Maintenance.

Do not classify a maintenance-personnel task as Operator Check merely because it contains words such as "check" or "inspect".

If the classification is genuinely ambiguous and materially affects the result, include it in the consolidated clarification questions.

TRADE:

For Preventive Maintenance, Trade is required.

Use an explicit trade or profession from the source whenever available.

Custom trade names used by the plant are allowed.

For Operator Check, Trade may remain blank.

Do not convert a person's name into a Trade.

When no Trade is provided but the maintenance activity clearly indicates the appropriate profession, make a reasonable recommendation.

Only infer Mechanic / Electrician / another trade when the task content gives strong evidence.

Do NOT infer a trade from an unexplained ERP group/code unless the source itself defines that code.

Only ask me when the correct trade cannot be reliably determined.

FREQUENCY:

The final Frequency must be one of these Riffhelm values:
- Daily
- Weekly
- Every 2 Weeks
- Monthly
- Quarterly
- Every 6 Months
- Yearly
- Every 5 Years

Normalize equivalent source descriptions automatically.

Examples:
7 days = Weekly
14 days = Every 2 Weeks
1 month = Monthly
3 months = Quarterly
6 months = Every 6 Months
12 months = Yearly

Common ERP codes may be normalized only when their meaning is explicit from the file/context, for example:
D-1 = Daily
W-1 = Weekly
W-2 = Every 2 Weeks
M-1 = Monthly
M-3 = Quarterly
M-6 = Every 6 Months
M-12 = Yearly
Y-1 = Yearly
M-60 = Every 5 Years

Do not ask me about obvious frequency conversions.

Do NOT assign a parent's frequency to an unrelated/unlinked detail row just because it appears nearby.

If the source contains a materially different or ambiguous frequency that cannot be safely mapped, ask me in the consolidated clarification round.

ESTIMATED MINUTES:

The final Estimated Minutes must use one of these values:
- 15
- 30
- 45
- 60
- 90
- 120
- 240
- 480

If the source provides a duration, convert it to minutes and choose the closest appropriate Riffhelm value.

Do not ask me about obvious rounding.

If the exact source duration is equally close to two allowed Riffhelm values, choose the HIGHER value so planning capacity is not understated.

When useful, preserve the original duration in Instructions / Notes if the normalized Riffhelm value differs materially from the source.

If no duration exists, make a reasonable task-based estimate only when confidence is sufficient.

Do not invent a precise-looking duration for a complex or unclear task.

If duration cannot be estimated reasonably, include it in the consolidated clarification questions.

REQUIRED PARTS:

Required Parts is optional.

When parts are provided by the source, preserve them.

Separate multiple parts using semicolons.

Do not invent required parts.

INSTRUCTIONS / NOTES:

Preserve useful maintenance instructions, procedures, safety information, comments, and relevant source details.

Do not discard useful information simply because it does not have a dedicated Riffhelm column.

Use Instructions / Notes to preserve useful detail that belongs to a canonical task but should not become a separate recurring task.

MISSING REQUIRED STRUCTURAL FIELDS:

Department and Asset / Machine are required to create the Riffhelm equipment structure.

A missing required field is NOT automatically True Unresolved.

Before escalating any record, perform the Mandatory Unresolved Rescue Pass defined later in this prompt.

If Department is missing:
- first search every supplied file and worksheet for the same asset code, asset name, alias, plan code, source ID, parent plan, task set, or classification;
- inspect explicit block / section / mapping context;
- inspect equipment lists and auxiliary columns;
- compare other records for the same physical asset;
- consider site-wide / infrastructure context ONLY if the supplied sources already contain an explicit department/category that supports that mapping;
- if a reasonable source-supported Department recommendation can be made, classify it as Level B Recommendation rather than Level C;
- otherwise do NOT invent a department.

A missing Department by itself is NOT sufficient reason for Level C when the available evidence supports a responsible recommendation.

If Asset / Machine is missing:
- search other files for a reliable target using plan code, task set, equipment code, parent/child structure, or explicit mapping;
- never invent a physical asset merely to complete the row.

If Frequency or Trade is missing:
- use explicit cross-file mappings and strong task context;
- prefer a recommendation when evidence is sufficient;
- escalate only when the decision remains materially uncertain.

Do not create fake departments, assets, trades, frequencies, or placeholder values such as "Unknown" or "Unassigned" unless the customer explicitly approves that choice.

LANGUAGE:

Source files may be in any language.

Understand the source language.

Preserve the plant's original terminology for Department, Asset / Machine, Task Description, Required Parts, and Instructions whenever practical.

Do not unnecessarily translate plant-specific names.

IMPORTANT DATA RULES:

Do not invent machines.
Do not invent departments.
Do not invent maintenance tasks.
Do not silently discard maintenance records.
Do not turn employee names into machines or trades.
Do not turn task codes into machine names.
Do not treat headings, totals, comments, calendar/status columns, weekday status cells, or formatting rows as maintenance tasks.

Use workbook context such as:
- sheet names
- section headings
- surrounding rows
- merged cells
- repeated structures
- equipment codes
- plan codes
- operation numbering
- source hierarchy

in order to correctly interpret the source files.


==================================================
MANDATORY MULTI-PASS RECONCILIATION — BEFORE RECOMMENDATIONS
==================================================

Do not classify records as unresolved after only one extraction pass.

Complete these passes in order:

PASS 1 — EXPLICIT EXTRACTION
- extract direct Department, Asset, Task Type, Trade, Frequency, duration, parts, notes, plan codes, source IDs and parent/child structure;
- scan every worksheet and the full used range.

PASS 2 — CROSS-SOURCE ENRICHMENT
- search all supplied files for the same asset, alias, equipment code, source ID, plan code, recurring plan, task set or mapping;
- enrich missing fields only when the evidence is compatible.

PASS 3 — ASSET / ALIAS RECONCILIATION
- identify clear aliases for the same physical asset;
- keep separate assets separate when identity is uncertain;
- never merge solely on a similar name.

PASS 4 — LEGACY / SUPERSESSION ANALYSIS
- detect whether older, legacy, historical, superseded, renamed, replaced or migrated records represent the same real maintenance work as a newer/current representation;
- use evidence such as explicit asset identifiers, version/date context, active/inactive status, recurring plan identity, task-set similarity, source hierarchy, newer detailed files, and replacement/renaming relationships;
- never assume that an older code or older date alone proves supersession.

PASS 5 — PARENT / CHILD, GROUPING AND DUPLICATE RECONCILIATION
- distinguish parent plans, child actions, instructions, alternate source representations and independent recurring tasks;
- create canonical grouped treatments where justified;
- consolidate true duplicates;
- preserve separate work when duplicate status is uncertain.

PASS 6 — UNRESOLVED RESCUE PASS
- revisit every record still missing a required decision;
- determine exactly which field or relationship is unresolved;
- search all sources again specifically for that missing decision;
- attempt a responsible Level B recommendation before using Level C;
- group repeated missing decisions into one recommendation where possible.

Only after ALL SIX passes may a record be labeled True Unresolved.

==================================================
LEGACY / SUPERSESSION PASS — PREVENT FALSE NEW TASKS
==================================================

Historical systems often contain old asset codes, renamed equipment, retired identifiers, migrated plan records, archived plans, or multiple generations of the same maintenance program.

Before importing any apparently "additional" legacy record as a new recurring task, test whether it is actually another representation of maintenance work already represented by a current canonical record.

A legacy/supersession match may be High confidence when several independent signals align, for example:
- same physical asset or a clearly evidenced alias;
- same or successor asset identifier;
- same Department / area;
- same recurring frequency;
- same maintenance scope or materially matching task set;
- newer detailed source clearly covers the same visit;
- explicit replacement / rename / migration relationship;
- source status or chronology supports the newer representation as current.

If High confidence:
1. Do NOT create a second recurring task.
2. Keep the current / richer canonical representation.
3. Merge useful non-conflicting details from the legacy record when appropriate.
4. Account for the old record as:
   "Consolidated as legacy / superseded representation."
5. Preserve traceability to the source.

If Medium confidence:
- create ONE Level B recommendation describing the proposed legacy/supersession consolidation and affected records.

If Low confidence:
- do not silently suppress the record;
- preserve it separately or classify it as Level C if a customer decision is required.

IMPORTANT:
Legacy/supersession analysis is not permission to delete old-looking records.
It is an evidence-based reconciliation step.

==================================================
DUPLICATE PREVENTION — MANDATORY CROSS-SOURCE AUDIT
==================================================

Prevent duplicates across:
- worksheets inside the same workbook;
- different source files;
- summary vs detailed files;
- parent plan vs child actions;
- old vs current asset identifiers;
- aliases / renamed assets;
- repeated exports of the same maintenance program;
- legacy / migrated system records.

Use a layered duplicate test.

Do NOT rely only on exact text equality.

Compare:
- physical asset identity;
- Department / area;
- Task Type;
- Trade;
- Frequency;
- maintenance scope / same visit;
- parent plan identity;
- child action set;
- plan/source IDs;
- timestamps / versions / active status where available.

Two rows with similar wording are NOT automatically duplicates.
Two rows with different wording MAY still be duplicate representations of the same recurring maintenance visit.

Before final output:
- run one complete cross-source duplicate audit against the canonical task list;
- ensure no legacy or summary representation creates a second copy of an already represented treatment;
- ensure grouped child actions are not repeated as standalone recurring tasks unless independently scheduled.

==================================================
UNRESOLVED COUNT INTEGRITY
==================================================

Do not inflate unresolved counts.

A source record may have only ONE final accounting outcome.

Do not count the same real record twice because it appears:
- in both summary and detailed files;
- as parent and child;
- under both old and new identifiers;
- in repeated exports;
- in more than one reconciliation category.

Report both:
- source records analyzed; and
- canonical recurring tasks / outcomes after reconciliation.

These are different concepts.


==================================================
RECOMMENDATION ROUND — REQUIRED
==================================================

Your goal is to resolve as much of the customer's maintenance data as possible WITHOUT inventing facts and WITHOUT forcing the customer to manually review hundreds of rows.

After analyzing ALL supplied files, classify unresolved items into three levels:

LEVEL A — AUTO-RESOLVE
Use when the evidence is explicit or confidence is high enough that no customer decision is reasonably required.
Examples:
- explicit Department mapping found elsewhere in the workbook;
- explicit Trade in another matching source;
- obvious frequency normalization;
- exact duplicate representation;
- parent-plan / child-action relationship that is structurally clear.

Proceed automatically and document the decision in the final summary.

LEVEL B — RECOMMENDATION
Use when the source is incomplete or ambiguous but there is enough evidence to make a reasonable, useful recommendation.

For each recommendation include:
1. What needs to be decided.
2. Recommended value/action.
3. Short reason / evidence.
4. Confidence: High / Medium / Low.
5. How many records / assets / tasks are affected.

Examples:
- "Recommend Department = [source-supported department] for a group of assets because they all appear inside the same explicit department block or mapping in the source."
- "Recommend Trade = Mechanic for 12 PM tasks because the source descriptions are mechanical maintenance actions and no conflicting trade appears elsewhere."
- "Recommend Monthly because the source code M-1 and surrounding plans consistently represent a monthly cycle."
- "Recommend grouping these 7 actions into one Monthly Preventive Maintenance parent task because Department, Asset, Trade, Frequency, Task Type and scope all match."
- "Recommend keeping both records because the descriptions are similar but the source IDs / trades / scopes differ."

IMPORTANT:
Do not ask one question per row.

Group recommendations by shared decision whenever the same answer can safely apply to multiple records.

Present one consolidated RECOMMENDATION ROUND with a short numbered list or compact table.

Give the customer simple response options such as:
- ACCEPT ALL RECOMMENDATIONS
- ACCEPT ALL EXCEPT 3 AND 7
- 3 = change to another approved trade
- 7 = keep separate

After the customer answers, apply the accepted recommendations to ALL affected records and finish the file without restarting the analysis.

LEVEL C — TRUE UNRESOLVED
Use only AFTER the Mandatory Multi-Pass Reconciliation and Unresolved Rescue Pass have been completed and there is still not enough evidence to make a responsible recommendation.

A record must NOT become Level C merely because:
- one field is blank in the first source checked;
- Department is not repeated on every row;
- the asset uses an older identifier;
- the record appears in a legacy export;
- the same decision affects many records;
- the required answer is inferable with reasonable source-supported confidence.

For these cases:
- explain exactly what is missing or conflicting;
- state what rescue checks were attempted;
- ask one concise direct question;
- where possible, still provide the safest recommendation and confidence;
- do not invent a value just to achieve 100% completion.

==================================================
MAXIMIZE RESOLUTION — WITHOUT INVENTION
==================================================

The objective is NOT to leave every incomplete field unresolved.

Use cross-file evidence aggressively but safely.

Before asking the customer:
- search all workbooks for the same asset;
- search other worksheets for Department / Trade / Frequency mappings;
- use ERP / CMMS / legacy system block structure;
- compare similar tasks on the same or clearly equivalent equipment;
- use explicit plan codes and source IDs;
- use parent/child plan relationships;
- use repeated plant conventions that are clearly evidenced in the supplied files.

When a recommendation can be based on these sources, recommend it.

Do NOT invent:
- a Department with no evidence;
- a machine that does not exist;
- a maintenance task that does not exist;
- a part that is not in the sources;
- a frequency that contradicts explicit source data;
- a Trade when the available evidence is materially conflicting.

==================================================
GROUPED TREATMENTS — RECOMMEND, DO NOT FLATTEN
==================================================

When several actions are candidates for one grouped treatment, evaluate:

Department
+ Asset / Machine
+ Task Type (PM/Operator Check)
+ Trade
+ Frequency
+ compatible maintenance scope

If these align and the source structure supports one maintenance visit/treatment:
- recommend ONE parent task;
- preserve ALL real child actions as checklist bullets inside Instructions / Notes;
- do not silently discard any action;
- do not create one recurring PM row per child action.

If grouping is high-confidence and clearly represented by a parent plan in the source, auto-resolve.
If grouping is reasonable but not certain, include it as ONE grouped recommendation, not many row-level questions.

Never group:
- different assets;
- different frequencies;
- PM and Operator Check;
- different Trades where separate execution is operationally required;
- actions whose scope is materially different.

Grouping is separate from duplicate deletion.
Two actions inside the same grouped treatment are not duplicates merely because they are similar.

==================================================
RESOLUTION ACCOUNTING — NOTHING MAY DISAPPEAR
==================================================

Every source maintenance record must end with a traceable outcome.

Use these outcome categories:

- Imported / Auto-resolved
- Imported / Recommendation accepted
- Consolidated into grouped treatment
- Consolidated as confirmed duplicate representation
- Consolidated as legacy / superseded representation
- Rescued through cross-source recommendation
- Preserved as separate task
- True Unresolved / customer decision required
- Excluded as non-maintenance metadata / heading / subtotal / historical-only row

Do not silently drop records.

At the end, report counts for:
- source files processed;
- source maintenance records analyzed;
- auto-resolved records;
- recommendation-resolved records;
- grouped parent treatments created;
- checklist actions preserved;
- duplicates consolidated;
- legacy / superseded representations consolidated;
- unresolved records rescued through second-pass recommendation;
- records preserved separately because duplicate status was uncertain;
- true unresolved records;
- non-maintenance structural/metadata rows excluded.

The goal is to maximize reliable resolution while preserving a complete audit trail.

CLARIFICATION RULE:

Avoid a long question-by-question conversation. Use the RECOMMENDATION ROUND above before escalating items to direct customer questions.

If important uncertainty remains after analysis:

1. Finish everything that can be completed reliably.
2. Collect the remaining important questions.
3. Ask them together in one concise numbered list.
4. Where useful, recommend the most likely answer.
5. Group repetitive uncertainty into one decision whenever possible instead of asking about dozens of rows separately.
6. Wait for my answers.
7. Then finish the file without restarting the analysis.

Example:

"I completed most of the conversion. I need 3 decisions before creating the final Riffhelm file:

1. One asset appears under two materially different names in the source files. Are these the same physical asset? I recommend using the clearest current detailed-source name if the evidence confirms they are aliases.
2. A group of source-system-only assets has no reliable Department in any supplied file. Should I leave these for a second pass, or do you want to provide a department mapping?
3. Several complex ERP tasks have no duration. May I use conservative task-based estimates where confidence is reasonable and list only the truly uncertain cases?"

DEPARTMENT COVERAGE CHECK:

Before the final quality check:
- compare the final Department values against the internal inventory of department labels discovered across ALL worksheets;
- verify that no explicit department/area was missed merely because it appeared in a sparse, far-right, hidden, merged or block-level field;
- report any discovered department that could not be safely mapped.


==================================================
MANDATORY CUSTOMER APPROVAL GATE — DO NOT SKIP
==================================================

This is a HARD STOP.

After you finish analyzing ALL source files:

IF there is at least ONE:
- Level B Recommendation, OR
- Level C True Unresolved item,

you MUST NOT create the final Riffhelm XLSX yet.

You MUST:

1. Complete all Level A auto-resolution first.
2. Build the consolidated RECOMMENDATION ROUND.
3. Show the customer:
   - what was resolved automatically;
   - every grouped recommendation;
   - recommended value/action;
   - reason/evidence;
   - confidence;
   - number of affected records/assets/tasks;
   - all True Unresolved questions.
4. Ask for ONE consolidated customer response.
5. STOP.

Do not continue.
Do not create the final XLSX.
Do not silently accept your own recommendations.
Do not assume "the customer probably agrees."
Do not treat a request to "prepare the file" as approval of recommendations.

Wait for explicit customer approval or changes.

Valid customer approval examples:
- ACCEPT ALL RECOMMENDATIONS
- ACCEPT ALL EXCEPT 3 AND 7
- ACCEPT 1,2,4; CHANGE 3 TO ELECTRICIAN
- KEEP 7 SEPARATE
- answers to the listed True Unresolved questions

Only AFTER the customer answers may you:

1. Apply the accepted/changed recommendations.
2. Resolve the affected records.
3. Recalculate grouped treatments if needed.
4. Run the final quality checks.
5. Produce the final Riffhelm .xlsx file.

EXCEPTION:
If there are ZERO Level B Recommendations AND ZERO Level C True Unresolved items,
you may proceed directly to the final XLSX after Level A auto-resolution and quality checks.

This approval gate is mandatory and overrides any instruction that would otherwise cause you to immediately generate the final XLSX before customer review.

FINAL QUALITY CHECK:

Before producing the final file, verify that:

1. The Riffhelm column structure has not changed.
2. Every output row represents a real recurring maintenance treatment or operator check.
3. Grouped treatments are ONE parent row with at least TWO real actionable bullet lines in Instructions / Notes.
4. Every grouped source action is preserved in the checklist; no action was silently lost.
5. Child checklist actions are not duplicated as separate recurring rows unless independently scheduled.
6. Mechanic and Electrician PMs are not grouped together.
7. PM and Operator Check are not grouped together.
8. Different frequencies or different equipment are not grouped together.
9. Grouping was not used as silent duplicate deletion.
10. Instructions/details were not incorrectly converted into extra recurring tasks.
11. Department and Asset / Machine relationships are logical and source-supported.
12. No obvious duplicate recurring tasks remain across files/sheets.
13. Task Type contains only valid Riffhelm values.
14. Preventive Maintenance rows contain a Trade.
15. Frequency contains only valid Riffhelm values.
16. Estimated Minutes contains only valid Riffhelm values.
17. Required Parts are formatted correctly.
18. No important source records were silently lost.
19. No unsupported Department, Asset, Trade, Frequency or task was invented.
20. Summary / ERP / CMMS sources and detailed sources were reconciled into canonical parent + checklist treatments rather than duplicated.
21. Every Level C item passed the Mandatory Unresolved Rescue Pass first.
22. Missing Department alone was not treated as Level C when a source-supported recommendation was available.
23. Legacy / superseded records were checked against current canonical tasks before being added.
24. No legacy / old-identifier representation created a duplicate recurring task.
25. No source record was counted twice in unresolved accounting.
26. Final canonical tasks were checked again for exact and near-duplicate recurring maintenance scope across all sources.

==================================================
FINAL GENERICITY AUDIT
==================================================

Before returning the result, verify that your reasoning did not rely on any pre-known factory-specific mapping.

The conversion must still work correctly if the supplied files come from a completely different company, industry, language, ERP/CMMS, department structure, trade structure, and asset naming system.

Do not introduce any company-specific, plant-specific, equipment-specific, vendor-specific, or historical mapping that is not present in the customer's supplied sources.

FINAL DELIVERABLE:

IMPORTANT:
The final XLSX is produced ONLY after the Mandatory Customer Approval Gate has been satisfied,
unless there were zero Level B Recommendations and zero Level C True Unresolved items.

Provide:

A. One completed Riffhelm .xlsx file ready to upload into Riffhelm.

B. A short summary stating:
- number of source files processed
- number of parent maintenance tasks created
- number of grouped/consolidated treatments created
- total checklist actions preserved inside grouped treatments
- number of single-action treatments
- number of obvious duplicate representations consolidated
- number of legacy / superseded representations consolidated
- number of unresolved records rescued during the mandatory second pass
- number of ambiguous duplicate candidates left for decision
- important assumptions made
- clarification decisions supplied by the user
- anything that could not be safely interpreted
- number of records auto-resolved
- number of records resolved through accepted recommendations
- number of grouped parent treatments created
- number of checklist actions preserved
- number of true unresolved records

Do not create an alternative spreadsheet format.

The final deliverable must use the official Riffhelm template.