Cursor Rules Template: Injection Molding Root Cause Analysis with Batch and Defect Records

Overview

The Cursor rules configuration page provides a copyable .cursorrules block and stack-specific guidance to build AI powered root cause analysis tools for injection molding. This template targets a Python + PostgreSQL stack and focuses on batch and defect records to surface explainable RCA insights. It includes a deterministic, auditable workflow for data processing, model inference, and result publication in manufacturing environments.

Direct answer: paste the included .cursorrules block into your project root to configure Cursor AI for injection molding RCA using batch and defect data, then follow the recommended project structure and security rules.

When to Use These Cursor Rules

• You are building an AI driven RCA for injection molding using batch and defect records.
• You need reproducible data processing, auditable results, and traceable data lineage from raw batches to RCA outputs.
• You require stack-specific guidance for a Python + PostgreSQL data layer, including ORM usage and validation rules.
• You want a copyable configuration that teams can drop into their project root for fast onboarding.

Copyable .cursorrules Configuration

Framework Role & Context
You are a Cursor AI helper for building root cause analysis tools on a Python + PostgreSQL stack. You operate with batch and defect data from injection molding lines. Provide auditable, reproducible results and clear lineage from input data to RCA outputs.

Code Style and Style Guides
Follow Black for Python, isort for imports, mypy for type hints. Use docstrings and explicit typing. Adhere to PEP 8. Name modules and functions clearly, prefer explicit over implicit.

Architecture & Directory Rules
Project layout:
project/
  data/
    batches.csv
    defects.csv
  src/
    api/
    models/
    engines/
  tests/
  .env
  requirements.txt
  README.md

Authentication & Security Rules
Do not embed credentials in code. Load DB_CONNECTION from environment. Use SSL for DB connections. Rotate keys and enforce least privilege on database roles. Do not log secrets in plaintext.

Database and ORM patterns
Use PostgreSQL with SQLAlchemy ORM. Define tables: batches, defects, rca_results. Use declarative_base. Index batch_id and defect_id. Use Alembic for migrations. Store feature lineage and data provenance with each RCA run.

Testing & Linting Workflows
pytest for unit and integration tests. Use pytest-cov for coverage. Run Black, isort, and mypy in CI. Validate data with unit tests using small synthetic batches and defects datasets.

Prohibited Actions and Anti-patterns for the AI
Do not modify live production data. Do not bypass validation or data provenance tracking. Do not rely on brittle heuristics without traceability. Do not expose credentials or secrets in logs, tests, or outputs.

Recommended Project Structure

project-root
├── data
│   ├── batches.csv
│   └── defects.csv
├── src
│   ├── api
│   │   └── app.py
│   ├── models
│   │   └── rca_model.py
│   └── engines
│       └── rca_engine.py
├── tests
│   ├── test_rca.py
│   └── conftest.py
├── .env
├── requirements.txt
└── README.md

Core Engineering Principles

• Reproducibility: deterministic data processing and model steps with clear provenance.
• Observability: structured logging, metrics, and traceability from input to RCA output.
• Security by design: secret handling, least privilege, and encrypted connections.
• Data quality gates: validation, schema checks, and anomaly detection before RCA runs.
• Modularity: separation between data access, feature engineering, and RCA logic.

Code Construction Rules

• Use SQLAlchemy ORM models for batches, defects, and rcas to ensure consistent queries.
• Encapsulate feature extraction in small, testable functions with explicit inputs and outputs.
• Validate input batch and defect data with schema checks before RCA processing.
• Store RCA results with timestamps and data provenance to enable audit trails.
• Avoid hard-coded thresholds; prefer data-driven, documented thresholds with versioning.
• Document API surfaces and data contracts in a central docs file within the repo.

Security and Production Rules

• Use SSL for all DB connections and API endpoints.
• Never log secrets; use environment-based configuration with secret masking in logs.
• Enforce role-based access control for data operations (read batches, read defects, write rcA results).
• Implement input validation, data sanitization, and provenance tagging for every RCA run.
• Enable automated backups and point-in-time recovery for the main database.

Testing Checklist

• Unit tests for data validators and feature extractors.
• Integration tests for batch and defect ingestion pipelines.
• End-to-end tests for a full RCA run from data load to results publication.
• CI workflow verifying linting, typing, tests, and regression checks.
• Verify reproducibility of RCA results with fixed random seeds where stochastic components exist.

Common Mistakes to Avoid

• Skipping data validation leading to unpredictable RCA results.
• Bypassing provenance tracking or mislabeling data lineage.
• Overfitting RCA models to a single batch; ensure generalization across lots.
• Exposing DB credentials or secrets in logs or code repositories.
• Mixing data access and presentation layers without clear boundaries.

Related implementation resources: AI Agent Use Case for Electronics Manufacturers Using Automated Test Equipment Logs To Isolate Batch Component Failures and Threat Auditing AI Systems: Simulating Malicious User Inputs to Validate Defenses.

FAQ

What is this Cursor Rules Template for?

This Cursor Rules Template provides a ready-to-paste .cursorrules block and stack guidelines to build an AI driven root cause analysis tool for injection molding using batch and defect records on a Python + PostgreSQL stack. It outlines architecture, data models, security, testing, and anti-patterns to keep development focused and auditable.

Which stack does this template target?

The template targets a Python 3.x + PostgreSQL stack with SQLAlchemy ORM for data access, Pandas for data manipulation, and a modular design that separates data ingestion, feature engineering, and RCA reasoning. It emphasizes reproducibility, provenance, and secure data handling in manufacturing contexts.

How do I insert the .cursorrules block into my project?

Copy the code block from the Copyable section and place it in a root level file named .cursorrules. Ensure your project root matches the architecture guidelines outlined in the template and adjust paths for your repository structure.

What security considerations should I follow?

Use environment variables for secrets, enforce SSL connections to PostgreSQL, implement least privilege roles, avoid logging sensitive data, and keep an auditable trail of RCA runs with provenance metadata. Rotate credentials periodically and store secrets in a secure vault where possible.

How should I test the RCA tooling?

Write unit tests for validators and feature extraction, integration tests for data ingestion, and end-to-end tests that simulate a complete RCA run. Use fixed seeds for any stochastic components to ensure reproducibility of results across runs.

What are common pitfalls to avoid?

Avoid bypassing data validation, failing to track provenance, hard coding thresholds, and exposing secrets. Keep data contracts explicit, ensure migration and versioning, and maintain clear boundaries between data access, analysis, and presentation layers.