Case study · Platform record · Platform record · Workflow & decisions

Forge

We built Forge as the procedure layer in the stack: versioned workflows, decision gates, and a reviewable handoff record under the products already in the field.

Forge system

Who
Departmental process owners and supervisory desks
Where
In the Vinkura operating stack — under DDMS, e-Maalkhana, and E-CTC
Mission
Make the authorised path explicit without removing judgement
Forge workflow and decision automation surface
States, responsibilities, conditions, and evidence requirements.

01 / The situation

Institutional work fails when procedure lives only in circulars, registers, and individual memory. Files wait on desks with no escalation. Handoffs depend on who knows whom. After the fact, nobody can show who held the work, for how long, or under which rule.

Forge is not a fake yatra deployment. It is in the stack as the system that turns approved policy into the path DDMS reliefs, e-Maalkhana movements, and E-CTC stage-gates already follow. The field products are the proof; Forge is the procedure underneath them.

02 / What we built

We built Forge to model an approval or operational process as a controlled graph of roles, conditions, deadlines, and escalation paths. Role-based access is enforced at each transition. Every state change creates an audit entry. Human judgement stays where policy demands it — as a recorded decision gate, not an invisible skip.

Existing applications can remain systems of record. Forge manages execution and accountability. That is how e-Maalkhana custody transitions and E-CTC case stages stay consistent without each product inventing its own procedure engine.

  1. 01Model

    Translate approved procedure into versioned states, responsibilities, and evidence requirements.

  2. 02Assign

    Route work to the authorised role with the required context.

  3. 03Decide

    Apply checks, approvals, evidence, and recorded judgement.

  4. 04Improve

    Review delay and exception patterns without weakening procedure.

Procedure modelling

Departmental processes as versioned states, not a one-off flowchart in a slide.

Decision gates

Require review where authority, risk, or policy demands a person — and keep that review on the record.

Exception handling

Escalate delays, incomplete records, and non-standard cases to the desk policy names.

Process audit

Inspect who acted, what changed, which rule applied, and where a case is held.

03 / How it ran

When a custody item stops moving, or a case stage stalls, or a duty relief is waiting on an approval, Forge is the reason the authorised desk, the elapsed time, and the next escalation are visible. That is already how the field products behave; this record is the layer that makes those paths consistent.

Coverage sits on the products Forge underwrites: Amar Ujala on e-Maalkhana, Dynamite News on DDMS, The Hindustan Wires on the platform.

04 / What changed

Handoffs become visible. Delays become accountable. Commanders gain a current view of bottlenecks without chasing a physical file.

The institution owns the rules and the audit record that govern how work moves, including when a procedure version changes.

05 / Where we take this

We are taking Forge from embedded product workflows into department-authored procedure libraries so a new circular can become a versioned path without a custom build.

Next on our side: more of E-TA/DA and Personnel running on the same gates, and Sentinel visibility of stalled Forge work beside live operations.

06/ News & media

Forge has no separate named-system clip. These are the field and platform stories whose workflows it underwrites.

08 / Request a briefing

Talk to us about running this architecture in your district, unit, or command. We brief from the systems we have already deployed — not from a slide of hypotheticals.

Request a briefing