Autonomous QAF Comparison Audit, Adaptive Engine and SupplierPulse Implementation You are the autonomous lead engineer and domain expert responsible for auditing, redesigning, implementing, testing and integrating the complete QAF comparison capability directly into the existing SupplierPulse application. You are acting simultaneously as: • senior automotive cost engineering expert • BMW QAF domain specialist • Excel forensic analyst • financial and commercial data quality expert • multilingual data modelling expert • requirements engineer • senior software architect • backend engineer • frontend engineer • database engineer • QA and test automation engineer • security engineer • DevOps and release engineer • technical product owner This is not a theoretical review and not merely a recommendation task. You must autonomously inspect the provided documents, inspect the complete existing SupplierPulse implementation, identify all gaps, design the correct target architecture and implement the required improvements directly in SupplierPulse. The final result must be production-grade, modular, accurate, explainable, bilingual, maintainable and robust against future QAF changes. 1. Mandatory source documents Analyze the following files completely: 1 Fehlerreport (1).xlsx 2 MAN_aktuell_Nutzerleitfaden_QAF_de.pdf Inspect every relevant element of both files. For the Excel workbook, inspect: • every German and English worksheet • every row and column • hidden worksheets • hidden rows and columns • formulas • calculated values • displayed values • comments • notes • merged cells • named ranges • data validations • conditional formatting • formatting with semantic relevance • workbook metadata • language-specific differences • discrepancies between the German and English error reports • fields marked as required or optional • reported system feedback • incorrect classifications • missing values • fields that are necessary for comparison • fields that are necessary only for validation • fields that are informational For the PDF, inspect: • all 99 pages • all text • all diagrams • all screenshots • all formula illustrations • all field descriptions • all table structures • all business rules • all QAF variants • all currencies • all languages • all referenced forms • all exceptions • all input fields • all calculated result fields • all protected fields • all optional sections • all dependencies between worksheets Do not rely only on extracted text. Inspect visual diagrams, tables and screenshots where necessary. Do not skip content because it appears repetitive. 2. Source hierarchy Apply the following evidence hierarchy: 1 Official QAF user guide as normative functional documentation. 2 Actual formulas and workbook structures in representative QAF files. 3 Fehlerreport (1).xlsx as empirical defect and validation evidence. 4 Existing SupplierPulse behavior and source code. 5 Existing automated tests. 6 Clearly labelled expert inference where documentation is incomplete. Existing code and tests are not automatically correct. A passing test proves only that the implemented behavior matches the test. It does not prove that the behavior matches the QAF specification. When sources conflict: • identify the conflict • record the exact source locations • explain both interpretations • determine the safest expected behavior • assign a confidence level • implement only behavior that is sufficiently supported • place unresolved rules in configurable review status • never silently guess 3. Mandatory autonomous execution Do not stop after analysis. Perform the complete work autonomously: 1 Analyze the documents. 2 Inspect the current SupplierPulse architecture. 3 Reconstruct the existing QAF comparison flow. 4 Identify functional, technical and UX gaps. 5 Design the adaptive target architecture. 6 Create or update implementation tickets if the project uses Linear or another issue system. 7 Implement the required backend changes. 8 Implement the required frontend changes. 9 Implement database migrations where needed. 10 Implement German and English localization. 11 Implement automated tests. 12 Implement migration and backward compatibility logic. 13 Run all quality and security gates. 14 Fix all issues introduced by the implementation. 15 Integrate the changes into the existing SupplierPulse application. 16 Merge and deploy according to the established project workflow, provided all required gates pass. 17 Verify the deployed functionality. 18 Document the implementation and operational behavior. 19 Produce a final evidence-based completion report. Do not merely create mockups, isolated prototypes or unused services. The functionality must be reachable and usable from the actual SupplierPulse QAF comparison workflow. Do not leave essential work as TODO comments. Do not claim completion when only a partial implementation exists. 4. Preserve and improve the current SupplierPulse solution The current QAF comparison functionality is already mature. Do not rebuild it blindly. First determine: • what already works correctly • what is architecturally sound • what users already rely on • what can be extended safely • what must be refactored • what must be replaced • what must remain backward compatible Preserve all correct and valuable behavior. Avoid unnecessary rewrites. Prefer incremental, testable improvements unless the existing design makes accurate comparison fundamentally impossible. The final implementation must remain consistent with: • existing SupplierPulse navigation • current project structure • current authentication and authorization • current tenant model • current data storage conventions • existing report design • current UI patterns • current German and English localization mechanism • current deployment process • established security controls • existing CI and quality gates 5. Core architectural principle Never build the comparison primarily around fixed cell addresses. Fixed cell positions may be used only as secondary evidence for a known and verified template version. The primary comparison model must be semantic, structural and version-aware. Use a layered identification strategy: 1 Embedded stable identifier, where available. 2 Named range or structured Excel metadata. 3 Canonical field identity. 4 Section and table context. 5 Normalized German or English label. 6 Unit and data type. 7 Formula role. 8 Neighbouring labels and structural anchors. 9 Known template position as fallback. 10 Confidence score. A field must not be mapped solely because it happens to occupy the same coordinate. 6. Canonical QAF domain model Create or improve a canonical, language-independent QAF domain model. Each canonical field should support at least: • stable canonical field ID • QAF module • QAF variant • logical section • logical subsection • German label • English label • known aliases • known spelling variants • expected data type • expected unit • expected currency dimension • input, calculated, protected or informational classification • mandatory, conditional or optional classification • row-level or summary-level classification • aggregation behavior • calculation role • formula signature where applicable • dependencies • business validation rules • comparison rule • materiality rule • supported template versions • source evidence • mapping confidence • deprecation status The canonical model must be configurable and extendable. It must not require a code change for every harmless label adjustment. Material changes to formulas, dependencies or field semantics must still require controlled validation. 7. Adaptive support for future QAF changes The system must continue to operate safely when future QAF files differ from previously known files. Possible changes include: • changed QAF version • new worksheet • removed worksheet • renamed worksheet • translated worksheet • moved section • inserted row • deleted row • inserted column • deleted column • reordered fields • changed field label • additional alias • new cost category • removed cost category • new QAF variant • changed formula • changed formula dependency • changed unit • changed currency logic • changed number format • changed named range • changed validation rule • newly hidden section • newly protected section • changed workbook metadata • new optional module • changed calculation basis • silent template modification without an updated version number Implement a template intelligence layer that: 1 Creates a structural and semantic fingerprint for each imported QAF. 2 Detects whether the template is known, modified or unknown. 3 Compares the fingerprint with known template profiles. 4 Detects formula and dependency changes separately from layout changes. 5 distinguishes harmless presentation changes from semantic changes. 6 Generates an automatic template change report. 7 Reuses high-confidence mappings. 8 Proposes mappings for new or changed fields. 9 assigns confidence scores to all inferred mappings. 10 blocks only unsafe comparison areas, not necessarily the complete file. 11 marks uncertain results clearly. 12 stores reviewed mappings as a new controlled template profile. 13 creates or updates regression fixtures for newly accepted versions. 14 keeps previous template profiles available for historical comparisons. The system must not silently treat a changed template as identical to an existing template. 8. Unknown template behavior When an unknown or modified QAF is uploaded, the system must autonomously: 1 Parse the workbook safely. 2 Detect language and QAF variant. 3 Detect known sections and fields. 4 calculate a template fingerprint. 5 compare it with known profiles. 6 map high-confidence fields automatically. 7 isolate uncertain fields. 8 run all safe comparisons. 9 run structural, formula and business-rule validations. 10 generate a template deviation summary. 11 identify which results are reliable. 12 identify which results require review. 13 store all evidence for later verification. Use explicit confidence thresholds. Recommended behavior: • High confidence: compare automatically. • Medium confidence: compare provisionally and mark the result. • Low confidence: do not use for commercial aggregation without review. • Contradictory mapping: block the affected comparison. • Unknown critical formula: block the affected calculated result. • Presentation-only change: accept automatically after validation. Do not classify the entire workbook as unusable when only one section is uncertain. Do not show a fully trusted overall result if critical sections remain unresolved. 9. German and English operation The complete SupplierPulse functionality must work in German and English. This includes: • QAF file parsing • QAF language detection • German QAF versus German QAF • English QAF versus English QAF • German QAF versus English QAF • mixed-language labels inside one workbook • German and English worksheet names • language-independent canonical mapping • localized decimal separators • localized thousand separators • localized date formats • localized percentages • German and English Excel formula representations • German and English error messages • German and English validation messages • German and English UI • German and English exports • German and English PDF reports • German and English audit trails • German and English field explanations Do not implement two separate comparison engines. Use one canonical engine with localized presentation and alias dictionaries. Preserve the original source label and show the canonical mapped field in the UI. Example: • Original label: Fertigungskosten • Canonical field: manufacturing_costs • English presentation: Manufacturing costs A German field and its English equivalent must compare as the same semantic field. 10. QAF variants and modules Support the complete structure required by the documents and existing SupplierPulse use cases. At minimum assess and support, where present: • SUMMARY • MATERIAL • MANUFACTURING COSTS • SBM-DEVICES-FWZ • LOGISTICS & CUSTOM • RAW MATERIAL RISKS • Standard QAF • Local Content China QAF • Carbon Footprint QAF • Sub-QAF structures • LAF • LEK • WAF • related manufacturing process checklists • additional QAF 9.1 modules found in the guide The architecture must allow additional modules without modifying the comparison core. Module-specific rules should be implemented through: • module definitions • field schemas • comparison policies • formula rules • validation rules • aggregations • localization resources • report sections 11. Dynamic row and position handling QAF detail sheets can contain dynamically generated rows. Never assume a fixed number of material, manufacturing or tool rows. Implement robust handling for: • dynamically added rows • deleted rows • reordered rows • multiple rows belonging to one logical position • repeated position numbers • fixed and variable material components • raw material risk split rows • blank trailing template rows • unintended blank rows inside an active data block • duplicated logical entries • multiple identical part descriptions • renamed but semantically equivalent entries Use appropriate logical keys. Depending on the module, possible matching dimensions include: • position number • process step • part designation • material designation • technical function • supplier • unit • raw material key • offer currency • procurement currency • tool type • billing type • stable row identifier • combination of several canonical attributes Do not match dynamic lines by row number alone. Detect additions, deletions, splits, merges and reclassifications. 12. Comparison dimensions The engine must perform separate but connected comparisons. 12.1 Structural comparison Detect: • added and removed worksheets • renamed worksheets • added and removed sections • moved fields • new fields • removed fields • reordered fields • changed merged cells • changed hidden content • changed named ranges • changed validations • changed protection • changed template metadata • changed QAF variant • changed QAF version 12.2 Semantic comparison Compare fields based on meaning rather than only their visible text or position. 12.3 Value comparison Correctly handle: • numbers • numbers stored as text • strings • booleans • dates • percentages • currencies • units • blanks • empty strings • zero • negative zero • error values • localized numeric formats • rounded values • different decimal precision • values in parentheses • calculated values • missing values • not-applicable values 12.4 Formula comparison Compare: • raw formula • normalized formula • calculation function • references • named ranges • dependency graph • constants embedded in formulas • operators • rounding • conditional logic • German and English function representations • relative and absolute references • same result with changed formula • changed inputs with unchanged formula • changed formula with currently identical result A hidden formula change must be reported even when the displayed value is unchanged. 12.5 Business-rule validation Validate the QAF logic independently of the workbook result. Examples include: • summary totals reconcile with detail sheets • material plus manufacturing equals manufacturing cost • manufacturing cost plus tool and scrap components reconcile to total cost • total cost plus other surcharges reconciles to base offer price • offer price components reconcile • currency allocations reconcile • exchange-rate relationships are plausible • quantities and units are compatible • scrap calculations use the correct basis • material risk rows follow their special rules • tools and fixtures reconcile with summary values • optional currencies are used only when activated • mandatory comparison fields are present • conditional fields are checked only when applicable Do not trust Excel-calculated results without independent validation. 12.6 Commercial impact comparison Calculate and explain: • absolute delta • percentage delta • percentage-point delta • quantity impact • unit-price impact • currency impact • total commercial impact • cost-driver contribution • increase or decrease • materiality • baseline issues • not-comparable results Handle zero and negative baselines explicitly. 13. Distinguish missing, zero and not applicable The error report demonstrates that empty and missing fields can have different consequences depending on whether a field is required for comparison or only relevant for validation. Implement an explicit field-state model: • provided valid value • provided invalid value • calculated valid value • calculated inconsistent value • empty but allowed • empty but conditionally required • empty and comparison-critical • zero valid • zero suspicious • not applicable • unavailable • mapping uncertain • formula unavailable • protected result unavailable • unsupported field Never treat empty, zero and not applicable as equivalent. Never generate a misleading comparison result when the required input basis is missing. 14. Error-report alignment Convert every finding in Fehlerreport (1).xlsx into: • a formal validation requirement • a defect or confirmed behavior classification • a reproducible test fixture • an automated regression test • a localized German message • a localized English message • an expected severity • an expected comparison consequence • an expected UI representation Compare the German and English error-report worksheets. Identify: • fields present in only one language • inconsistent required-field classifications • inconsistent pass or fail states • inconsistent system messages • translation mismatches • shifted or misaligned field mappings • different row counts • potential false positives • potential false negatives Do not assume the two worksheets are semantically identical merely because they are translations. 15. Comparison accuracy proof Do not state that the engine is accurate without evidence. Build an evidence-based validation matrix covering: • known good QAF pairs • known defect cases • German versus German • English versus English • German versus English • changed formulas with identical outputs • moved fields • inserted rows • deleted rows • renamed worksheets • unknown template versions • optional modules • multi-currency cases • raw-material-risk cases • incomplete files • partially corrupted files • protected workbooks • formula errors • stale cached data For every test fixture define: • source QAF • comparison QAF • expected mapping • expected structural differences • expected value differences • expected formula differences • expected business-rule violations • expected commercial impact • expected confidence • expected UI result • expected report result Measure at minimum: • field mapping precision • field mapping recall • false positive rate • false negative rate • critical difference detection rate • formula change detection rate • bilingual mapping accuracy • unsupported template detection rate Do not use false precision where the dataset is insufficient. 16. SupplierPulse user experience Integrate the functionality into the existing SupplierPulse QAF comparison area. The user must be able to: 1 Upload or select two or more QAF files. 2 Assign roles such as baseline, award, current, potential or scenario. 3 Start the comparison without technical configuration. 4 See detected QAF language, version and variant. 5 See whether the template is known, modified or unknown. 6 See comparison confidence. 7 See validation status before commercial results. 8 See critical blockers separately from warnings. 9 See added, removed, changed and unchanged positions. 10 See formula changes separately from value changes. 11 See structural changes separately from commercial changes. 12 Filter by QAF module. 13 Filter by severity. 14 Filter by cost increase or reduction. 15 open the exact source field or cell reference. 16 understand why two fields were mapped. 17 override an uncertain mapping when authorized. 18 preserve reviewed mapping decisions. 19 export a complete German or English report. 20 rerun the comparison after updated files are uploaded. The UI must clearly distinguish: • validated comparison • provisional comparison • manual review required • comparison blocked for affected section • unsupported template element • formula inconsistency • source-data quality issue Do not hide uncertainty behind a single green status. 17. Explainability and traceability Every comparison result must be traceable to: • source file • source worksheet • source cell or range • original field label • canonical field ID • original value • normalized value • formula, where applicable • comparison rule • mapping method • confidence score • applied unit conversion • applied currency conversion • calculated delta • validation result • QAF guide requirement • engine version • template profile version • timestamp Users must be able to understand why the system reached a conclusion. Keep the audit trail immutable for completed comparisons. 18. Configuration and rule governance Do not scatter QAF rules across frontend components and hardcoded backend conditionals. Create a controlled rule system for: • canonical field definitions • aliases • translations • template profiles • expected units • expected data types • required-field logic • conditional-field logic • formulas • tolerances • materiality thresholds • comparison rules • validation rules • report labels • module activation • mapping confidence thresholds Rules must be: • versioned • reviewable • testable • documented • backward compatible • auditable Critical formula or business-rule changes must not be activated silently. 19. Autonomous future adaptation Implement an autonomous adaptation workflow for future QAF files. When a new template difference is detected: 1 classify the difference 2 determine whether it is cosmetic, structural or semantic 3 run compatibility analysis 4 reuse safe existing mappings 5 propose new mappings 6 calculate confidence 7 generate regression fixtures 8 run the complete test suite 9 prepare a new template profile 10 activate automatically only when all safety criteria are met 11 otherwise require targeted review only for unresolved critical items 12 preserve the previous profile 13 log the decision 14 notify responsible users inside SupplierPulse Allowed automatic adaptation: • harmless label variations • recognized translations • reordered rows • moved fields • additional optional columns • changed formatting • changed sheet position • high-confidence aliases Not allowed without validation: • changed formula semantics • changed calculation basis • changed aggregation • changed currency logic • changed unit semantics • removed comparison-critical field • ambiguous field split or merge • new unknown cost category affecting totals Autonomy must never mean uncontrolled guessing. 20. Security and file safety Treat uploaded QAF files as untrusted input. Implement or verify protections against: • malicious macros • external workbook links • formula injection • ZIP bombs • oversized workbooks • corrupted XML • path traversal • embedded objects • unsupported binary formats • excessive sheet dimensions • resource exhaustion • dangerous hyperlinks • sensitive-data leakage • cross-tenant access • unauthorized export access Do not execute workbook macros. Do not follow external references automatically. Process files in an isolated and resource-limited environment where appropriate. Preserve confidentiality classification and existing access-control rules. 21. Performance and scalability The comparison must remain usable for: • multiple QAF files • many dynamically generated rows • multiple currencies • complete formula extraction • multiple historical comparisons • large workbooks • concurrent users Measure: • upload time • parsing time • comparison time • report generation time • memory usage • cache behavior • repeated comparison performance Do not improve speed by skipping formula, structural or validation checks. Use caching only with a reliable content hash and engine-version key. Never reuse stale results after the source file, template profile, comparison rules or engine version has changed. 22. Data model and persistence Persist at least: • original file metadata • cryptographic file hash • detected QAF version • detected language • detected variant • template fingerprint • template profile • parsing result • canonical normalized model • field mappings • confidence scores • formulas • dependency signatures • validation findings • comparison result • commercial deltas • manual review decisions • rule-set version • engine version • report version • audit log Ensure that historical comparison results remain reproducible after rule updates. Do not overwrite the evidence used for a completed comparison. 23. Backward compatibility and migration Existing SupplierPulse comparisons and historical data must not become unusable. Create a migration plan for: • existing cached JSON • existing normalized QAF data • existing comparison records • existing reports • existing field mappings • existing project links • existing user permissions Where full migration is unsafe: • preserve the old result • mark the previous engine version • offer a controlled recalculation • explain that recalculated results may differ • never silently replace historic results 24. Testing requirements Create comprehensive automated tests. Unit tests Cover: • field normalization • German and English aliases • number parsing • date parsing • percentage parsing • currency parsing • unit normalization • formula normalization • confidence scoring • template fingerprinting • materiality • delta calculations • required-field rules • conditional-field rules Integration tests Cover: • complete workbook parsing • dynamic rows • multi-currency QAF • raw material risk • Local Content • Carbon Footprint • LAF • LEK • WAF • German and English files • cross-language comparisons • unknown templates • database persistence • report generation Regression tests Create a regression test for every reproducible problem from Fehlerreport (1).xlsx. End-to-end tests Cover the real SupplierPulse workflow: 1 login 2 open project 3 open QAF comparison 4 upload files 5 validate files 6 start comparison 7 inspect findings 8 change filters 9 review uncertain mapping 10 export German report 11 switch to English 12 export English report 13 reopen saved comparison Security tests Cover hostile and malformed workbook cases. Performance tests Use realistic and worst-case QAF sizes. No defect may be considered fixed without a regression test. 25. Quality gates Before integration or deployment, run all project-standard gates. At minimum: • type checking • linting • unit tests • integration tests • regression tests • end-to-end tests • build • database migration validation • security scan • dependency audit • secrets scan • static analysis • performance smoke test • accessibility checks • German localization completeness • English localization completeness Do not weaken tests or disable quality gates to make the implementation pass. Do not remove existing safeguards. Fix root causes. 26. Safe release strategy Use a safe production rollout. Implement as appropriate: • feature flag • staged rollout • backward-compatible database migration • pre-deployment backup • health checks • comparison-result telemetry • error monitoring • rollback procedure • post-deployment verification Do not deploy if: • critical tests fail • data migration is unsafe • comparison accuracy regresses • critical mappings remain ambiguous • security controls fail • historical data could be corrupted • rollback is unavailable The final functionality must be enabled only when the defined release criteria are met. 27. Monitoring after deployment Implement operational monitoring for: • parsing failures • unknown template frequency • low-confidence mappings • blocked comparisons • formula inconsistencies • validation error rates • report-generation failures • performance regressions • German or English localization failures • unexpected template fingerprint changes • repeated user mapping overrides Use this information to identify new QAF variants and systemic weaknesses. Do not log confidential QAF values unnecessarily. 28. Required implementation backlog Create a prioritized implementation plan before coding. Use the following phases. Phase 0: Critical correctness risks Focus on defects that may create incorrect commercial conclusions. Phase 1: Adaptive canonical comparison engine Implement semantic mapping, template detection and normalized QAF models. Phase 2: Formula and business-rule validation Implement formula signatures, dependency checks and independent reconciliation. Phase 3: German and English support Complete bilingual parsing, comparison, UI and reporting. Phase 4: SupplierPulse integration Integrate the engine into the production workflow, persistence model and UI. Phase 5: Future template adaptation Implement template fingerprints, unknown-template workflow and controlled profile onboarding. Phase 6: Advanced explainability and monitoring Add confidence explanations, audit history and operational analytics. For each backlog item provide: • title • problem • evidence • scope • affected components • implementation design • dependencies • risk • acceptance criteria • automated tests • migration impact • deployment impact Then execute the backlog in dependency order. 29. Definition of done The task is complete only when all of the following are true: • both source documents have been fully analyzed • every relevant error-report finding is classified • every reproducible error has an automated test • the current SupplierPulse implementation has been audited • correct existing functionality has been preserved • an adaptive canonical QAF model exists • German files work • English files work • German versus English comparison works • known QAF 9.1 variants are handled • dynamically generated rows are handled • formula changes are detected • business-rule inconsistencies are detected • future template changes are detected • unknown templates are handled safely • confidence and uncertainty are visible • results are traceable to their source • functionality is integrated into SupplierPulse • database changes are safely migrated • reports work in German and English • all quality gates pass • deployment verification succeeds • rollback is documented and available • implementation documentation is complete • no critical or high-severity correctness defect remains open 30. Required final report Produce a final implementation report containing: A. Executive summary • what was analyzed • what was found • what was implemented • current production-readiness • remaining limitations B. Document coverage • all analyzed PDF pages • all Excel worksheets • hidden elements • inaccessible elements • implementation components reviewed C. Current-state findings • strengths • defects • architectural limitations • false-positive risks • false-negative risks D. Requirement catalogue Map official QAF requirements to SupplierPulse behavior. E. Error-report traceability For each Excel error-report row, show: • classification • implementation status • test case • final result F. Architecture Document: • canonical model • parsing • template profiles • mapping engine • comparison engine • formula engine • validation engine • persistence • frontend • reporting • monitoring G. Future-change robustness Demonstrate how the system reacts to: • moved fields • renamed labels • new rows • new columns • changed formulas • changed units • new worksheets • unknown template versions • German and English variants H. Accuracy evidence Report test coverage, known limitations and measured comparison quality. I. Implemented changes Provide: • changed files • migrations • APIs • UI components • tests • configuration • feature flags J. Deployment evidence Provide: • quality-gate results • deployed version • smoke-test results • monitoring status • rollback plan K. Remaining risks Clearly state any unresolved issue. Do not describe something as complete when it remains provisional. 31. Final operating principles Apply these principles throughout the task: 1 Accuracy before speed. 2 Semantic meaning before cell position. 3 Configuration before unnecessary hardcoding. 4 Independent validation before trusting Excel results. 5 Explicit uncertainty before silent assumptions. 6 Backward compatibility before destructive migration. 7 Reproducibility before opaque intelligence. 8 Automated tests before defect closure. 9 Safe autonomy before uncontrolled automation. 10 Direct SupplierPulse integration before isolated prototypes. The final objective is not merely to compare two spreadsheets. The objective is to provide SupplierPulse with a durable, autonomous and commercially reliable QAF intelligence system that can accurately compare German and English QAF files, detect hidden and visible changes, adapt safely to future QAF revisions and clearly explain every result to the user.