Modular IT Ticketing Platform

The project at a glance.

What it does.

How a ticket moves through the platform

1. 01

   Raised anywhere

   A requester uses the portal, sends an email or messages from a chat tool. The ticket, its audit entry and its event are written in one database transaction, whichever door it came through.

2. 02

   Triaged and given targets

   Business rules run, the matching SLA policy starts its clocks on the right business calendar, and AI triage runs afterwards in the background, so a slow model never holds up intake.

3. 03

   Worked in the workbench

   The queue refreshes as tickets change. An agent accepts or dismisses the triage suggestion, replies to the requester or adds an internal note, and logs time against the work.

4. 04

   Approved and fulfilled

   Requests that need approval wait for the line manager, who can decide from a phone. A fulfilment workflow then raises the task and tells the requester.

5. 05

   Resolved and learned from

   On resolution the AI's answer is scored against what the desk actually chose. A default workflow closes the ticket five days later unless the requester reopens it.

How it's built.

Technology

The hard parts, solved.

1. 01

   Letting AI act without losing control

   Triage is treated as a decision, not generated text: a provider answers typed questions with a confidence for each, and every decision is stored with its provider, model, latency and cost. Triage asks the JEV decision engine and, if it is outside the tenant's permitted regions, unpriced, over budget or down, the ticket simply keeps what intake gave it. The auto gate is read from that tenant's own record, and if people correct more than 5% of the last 100 applied answers, the platform drops back to suggest mode, audits the change and emails the administrators.

2. 02

   Tenant isolation that is tested, not assumed

   Row-level security is forced on every tenant table, and the migration script counts them on each run. The application connects through separate database roles for the table owner, the application, platform operations and read-only reporting, and a tenant-aware data client adds a second layer. The seed deliberately creates two tenants with identical ticket numbers and email local parts, so the release-blocking isolation suite would catch a leak that different-looking data might hide.

3. 03

   Reliable events inside a modular monolith

   Each state change writes its domain event to an outbox table in the same transaction, and consumers record what they have processed so a redelivery does no harm. Search documents and reporting data are projections that can be replayed from the event log. Because modules cannot reach into each other's tables, moving one into its own service later is a deployment change rather than a rewrite.

4. 04

   Service levels that are fair to everyone

   SLA clocks run on business calendars, pause while a ticket waits on the requester, a third party or an approval, and resume when it moves on. When AI triage in auto mode sets a ticket's category or team, the SLA module re-matches the policy but the clock keeps its original start, so a ticket never gains extra time because it was classified late.

5. 05

   Safe sessions and deliberately limited offline writes

   A shared backend-for-frontend package gives each app a server-side session behind an opaque __Host- cookie, rebuilds every proxied path from validated segments, forwards only allow-listed headers and checks the origin on writes, so no access token reaches the browser. Offline support is limited on purpose to three additive actions (report, comment, approve), because replaying anything that depends on the current state of a ticket could be wrong by the time it arrives.