SmartPlant EHS
The natural evolution of your business.
An EHS command center for multi-plant industrial manufacturers — permits, environment, and safety in one place, with an audit trail so compliance is visible, not buried in spreadsheets and email.
Overview
Environmental permits often live in spreadsheets, email, and filing cabinets. That makes missed deadlines, unclear ownership, and compliance gaps almost inevitable.
SmartPlant EHS replaces that fragmentation with one system. It can discover permits from sources such as EPA ECHO, DMAP, and state agencies (for example TCEQ), then runs the full permit lifecycle — owners, due dates, status, tasks, and attachments — with an audit trail of who changed what and when.
Safety and OSHA-aligned workflows sit beside environmental compliance: structured incident management (from reporting through investigation and closeout), optional OSHA Form 301–style fields for recordkeeping-ready case data, and CSV exports sized for internal ITA / recordkeeping handoff. Your team still owns official OSHA filings and severe-injury notifications.
Training and readiness stay visible with a training matrix and reminders so recurring safety requirements are harder to miss. EHS directors get a plant-level health score, environmental dashboards (for example TRI trends, enforcement, and facility context), and notifications. Plant supervisors see workload clearly. Built-in calendaring and messaging help corporate and site teams stay aligned.
Built for industrial manufacturers (starting with carbon black), SmartPlant EHS turns EHS compliance from a fire drill into a managed, auditable process — less risk, less scramble, and leadership visibility across permits, environment, and safety.
What you get
- One command center — permits, tasks, attachments, and history in a single place.
- Discovery plus lifecycle — agency-sourced context where it applies, then ownership, due dates, and status through renewal and evidence.
- Safety alongside environment — incidents, optional OSHA-style record fields, exports for your internal processes.
- Training visibility — matrix and reminders for recurring requirements.
- Leadership and plant views — health score, environmental dashboards, notifications, and clear workload for supervisors.
- Collaboration — shared calendar and messaging between corporate and sites.
Technology stack
The following reflects the current production application stack. (A separate target architecture for a future extraction is documented elsewhere and is not shown here.)
Application
| Layer | Technology | Notes |
|---|---|---|
| Language | Python 3.11 | Aligned with the production Docker image base. |
| Web UI / server | NiceGUI | Single-process app; Quasar/Vue on the client; page-based routing. |
| Entry | Python module | Application starts via python -m smartplantpermits.main after database migrations in the container. |
Data & persistence
| Layer | Technology | Notes |
|---|---|---|
| Database | PostgreSQL | Production-style relational store. |
| Driver | psycopg (binary extras) | Connection string uses postgresql+psycopg:// style in deployment configs. |
| ORM | SQLAlchemy 2.x | Domain models drive reads and writes. |
| Migrations | Alembic | Schema revisions are versioned and applied in order. |
| SQLite (ancillary) | aiosqlite | Available for lightweight or async SQLite scenarios where used. |
Security & configuration
| Layer | Technology | Notes |
|---|---|---|
| Password hashing | passlib + bcrypt | Includes legacy-compatible hashes where applicable. |
| Crypto | cryptography | Used for integrity and encryption helpers in sensitive flows. |
| Config | python-dotenv | Local .env; production relies on environment variables. |
Integrations & libraries
| Concern | Library | Notes |
|---|---|---|
| HTTP client | httpx, requests | External APIs — EPA, weather, agency discovery, and similar integrations. |
| Payments | stripe | Billing and webhooks as implemented in the product. |
| PDF reports | fpdf2 | Server-generated PDFs for permits, environmental views, and exports. |
Testing & quality
| Tool | Role |
|---|---|
| pytest | Unit and integration tests. |
| pytest-mock | Mocking helpers for isolated tests. |
Deployment & operations
| Item | Details |
|---|---|
| Docker | Application image plus PostgreSQL via compose for repeatable environments. |
| Volumes | Uploads and database persistence via named volumes. |
| Scripts | PowerShell / CMD helpers for deploy, restart, and database workflows on Windows and cloud hosts. |
Frontend assets
| Item | Details |
|---|---|
| Static files | Packaged static assets, uploads, logos, and rich text (for example TinyMCE) where enabled. |
| Styling | Utility-style classes, Quasar components, and shared theme tokens for a consistent UI. |
Dependency versions are tracked in the project requirements.txt; production Python should stay aligned with the application Docker image when debugging parity issues.