Kaveh Forge — Integrated Industrial Operations Platform

From AutomationOffice to Kaveh Forge

The project started with a focused problem: office automation, correspondence, secretariat workflows and organization structure. During development it became clear that correspondence was only one layer of the real operational problem. Engineering standards, inventory, production execution, costing, management reporting and internal collaboration all needed to work on the same model of organizational reality.

That evolution became Kaveh Forge: an integrated industrial and enterprise operations platform, with AutomationOffice as its original core. After roughly nine months of active development, the project is at 85% completion. Most operational domains are implemented; the remaining work is concentrated on final workflows, cross-domain acceptance testing, UX polish and production hardening.

This case study intentionally does not label the platform as finished. Its engineering value is the transition from isolated CRUD modules into an operational platform with explicit domain boundaries, lifecycle rules, authorization and traceability.

Business problem

Industrial organizations often operate through data islands:

• engineering maintains BOMs and routings in separate files or tools;
• warehouse teams keep stock and documents independently;
• production records machines, material usage and output in forms or spreadsheets;
• costing must reconcile data from several departments;
• correspondence and organization structure live in another system;
• access control depends on a small set of fixed roles;
• management builds the operational picture manually from exports.

The deeper problem is not duplicate entry. It is that each department owns a different version of operational truth. Kaveh Forge is designed to close that gap with a traceable chain from engineering standard to factory actual and period cost.

Platform architecture

The backend is a modular Django/DRF application on PostgreSQL. Redis supports caching and operational state; Celery and Celery Beat run background and scheduled work; Channels and Daphne provide realtime Inbox/Chat transport; and private files can live on S3-compatible object storage.

The frontend is built with Next.js and React around permission-aware workspaces rather than disconnected pages. Navigation and actions are derived from the user's effective capabilities. Persian enterprise UX, Jalali dates, searchable controls, standardized modals and interactive workflow guides are shared platform primitives.

Development, staging and production environments are separated through Docker Compose, with Nginx, Gunicorn and Daphne at the runtime edge.

1. Identity and centralized RBAC

Early versions relied on a handful of fixed user types. That stopped scaling once users could carry several business responsibilities at the same time.

The redesigned authorization model separates:

• Role — a bundle of software responsibilities
• Capability — an action-oriented permission such as inventory.post or backup.restore
• UserRoleAssignment — an auditable, optionally time-bound role assignment

Organizational position is intentionally separate from security authorization. Backend decisions and frontend navigation both consume effective capabilities, making multi-role users, read-only management access and future modules possible without inventing new combined role IDs.

2. Organization and personnel structure

The platform models company, locations, departments, positions and assignments instead of reducing the organization to a flat user list. This keeps organizational history separate from account identity and provides a foundation for correspondence, reporting and future HR workflows.

This area remains one of the domains receiving final workflow and personnel polish during the remaining project phase.

3. Correspondence and secretariat

AutomationOffice began here. The correspondence domain covers company structure, offices, secretariats, incoming/outgoing letters, recipients, subject/body, signatures, status and archive.

Iranian enterprise requirements are first-class: Jalali dates and numbering, organizational letterheads and generation of real Word documents are part of the domain flow rather than cosmetic add-ons.

The modern platform keeps formal correspondence distinct from everyday collaboration while connecting both through identity and Inbox concepts.

4. Master data and production engineering

Industrial master data includes Item, UOM, Operation, Work Center, Machine, Fixture, BOM and Routing.

BOM and Routing use controlled revision lifecycles. Active revisions cannot be casually mutated through ordinary CRUD paths; activation is a guarded workflow with domain validation.

Routing operations carry work center, machine, setup/cycle, operator and fixture information. Fixture-machine compatibility and physical constraints are revalidated before production release so an old ACTIVE flag cannot silently authorize a physically invalid new work order.

5. MES and production execution

MES does more than move an order from Draft to Done. On release, engineering standards become an execution snapshot:

• routing operations are frozen with sequence, work center, machine and fixture;
• BOM demand becomes immutable work-order material requirements;
• later engineering changes cannot rewrite an already released work order.

Execution records actual machine/time, material consumption, good output and scrap. Actual material lines can be linked back to their standard requirement. Actual quantity is intentionally allowed to differ from standard quantity; that difference is preserved as a production variance.

This gives reporting a clean answer to two separate questions: what was planned, and what actually happened.

6. Inventory and stock traceability

Inventory is posting-driven rather than a mutable stock counter. Documents and stock movements form the operational record, with lot/cardex traceability and searchable reporting.

MES material consumption and production output use the same inventory posting model. Production therefore cannot create one version of stock while the warehouse keeps another.

PDF and Excel exports support operational reporting without making spreadsheets the system of record.

7. Production costing

Costing consumes shared domain data instead of recreating it. For a Jalali accounting period, material rates, payroll, cost-center/overhead expenses and MES actuals contribute to product-period cost calculation.

Items and cost centers remain canonical Master Data resources. This avoids the common failure mode where finance, engineering and production each own a conflicting copy of the same entity.

The module is focused on auditable production cost, not on pretending to replace a complete financial-accounting or COGS system.

8. Management reporting and analytics

The platform API provides permission-aware aggregate reporting across production, inventory, costing and management domains. The frontend exposes these through a shared analytics workspace with Jalali quick ranges and custom date selection.

The value is operational visibility without manually reconciling exports from multiple applications.

9. Realtime Ticketing, Chat and Inbox

The collaboration layer includes Ticket, participants, chat groups, memberships, messages, replies, attachments and Inbox notifications. Channels/WebSocket transport supports realtime messages and events while backend membership rules remain authoritative.

Private/group chat, unread counters, reply/forward, emoji and attachments live inside organizational identity rather than an external messenger.

10. Operational Backup / Restore

Backup is an operational subsystem, not a database-download button. Schedule and Job models track automatic/manual operations, artifact metadata, file size and SHA-256 checksum. Database and media backup types are supported, with retention and Celery scheduling.

Restore is explicitly treated as a destructive operation: typed confirmation, artifact/checksum validation, a global lock, maintenance mode, database connection control and service verification are part of the design. backup.restore is intentionally separate from ordinary backup creation rights.

Media backup can include private object-storage content through a manifest-backed snapshot so user attachments are not excluded from business continuity.

11. Private object storage

Attachments and media are designed around an S3-compatible abstraction rather than hard-coding a single storage vendor. Environments can use different storage backends without rewriting domain code.

Private files are not modeled as permanently public URLs; access is tied to authorization or controlled temporary access.

12. Platform operations and system settings

Administrators can work with operational settings such as SMTP and inspect server health indicators such as CPU, memory and disk. Branding and a version/release contract are shared between backend and frontend so development, staging and production builds are identifiable.

Kaveh Forge branding is consistently applied to UI, About/version surfaces and document/report exports.

13. API facade and BFF

As the API surface grew, the frontend moved away from coupling every screen directly to internal backend URLs. Explicit allowlisted facades relay domain resources, and unsafe cross-origin mutations are rejected.

Frontend authentication uses an HttpOnly BFF session so backend credentials do not need to be casually exposed to browser JavaScript. The architecture also supports gradual migration toward a common /api/v1/ namespace.

14. Persian industrial UX

Enterprise UX is more than visual styling. Shared platform behavior includes:

• Jalali dates and common date controls
• searchable selectors for large master-data lists
• standardized modals instead of browser alerts
• permission-aware global navigation
• responsive workspaces and mobile quick access
• dark/light themes
• realtime Inbox/Ticket/Chat counters
• interactive “Training” tabs explaining each workflow
• clear lifecycle states, errors and empty states

Putting workflow education inside each workspace reduces dependence on external manuals and helps users understand the business process at the point of action.

Engineering strengths

Explicit separation of Standard and Actual

Engineering BOM/Routing are standards; a released Work Order snapshot is the production execution contract; MES actuals record factory reality. Keeping these layers separate makes variance and auditability possible.

Business rules live on the server

Activation, release, posting, authorization and restore safety do not trust UI behavior. The backend owns domain invariants even when the client is manipulated.

Shared source of truth across modules

Costing does not redefine Items and Cost Centers. MES does not maintain a separate stock truth. Reports aggregate canonical domain data. This reduces cross-department divergence.

Authorization that can grow

Role/Capability design replaces fixed combined role IDs and supports read-only users, managers and multi-responsibility staff without inventing a new user type for every combination.

Production operability is part of the product

Backup/restore, object storage, maintenance state, environment separation, pinned dependencies and health/reporting concerns are treated as product capabilities rather than deployment afterthoughts.

Value for industrial organizations

Why this project matters to me

Kaveh Forge is not the result of implementing one feature. It is the result of repeatedly redesigning architecture around real operational questions. The project began with correspondence and expanded into organization, engineering, inventory, MES, costing, reporting, RBAC, realtime collaboration and production operations.

Much of the difficult work lives in questions that simple CRUD systems never answer: What happens when a BOM changes after release? What if a role is temporary? What if restore fails midway? How should a private attachment be backed up? What if actual material consumption differs from standard? What happens when two modules try to own the same business entity?

Those questions are what turned AutomationOffice into an industrial software-engineering project.

Current status — 85%

After roughly nine months of active development, Kaveh Forge is at 85% completion. Master Data/Engineering, Production/MES, Inventory, Costing, RBAC, Backup/Restore, Ticketing/Chat, correspondence and management reporting all have implemented operational foundations, with substantial portions tested in staging/production workflows.

The remaining 15% is focused on completing the last organization/personnel flows, full cross-domain acceptance testing, final deployment/observability hardening, UX polish and organizational rollout closure rather than building the platform core from scratch.