Ticket Workflow

The authoritative lifecycle, SLA/escalation, proof-of-resolution gate, TRI/MoM, and edge-case specification for every ticket on the Sindh IT Portal — Facilitation Desk (SITP).

1. Scope & Definitions

This document defines how a ticket is born, routed, worked against an SLA, escalated, proven resolved, optionally re-opened or appealed, and finally closed — plus how meetings (TRI) and their Minutes (MoM) attach into the lifecycle. It is the single source of truth for the status field on tickets, the sla_definitions table, the ticket_history / audit_events logs, and all transition guards.

Glossary (short form; see _glossary.md):

All capabilities described here are individually toggleable via the Feature Flag module (Q) and individually configurable via the per-department / per-category configuration tables described in §15.

2. Ticket States

Every ticket has exactly one status at any time. The full enumeration is fixed; entry and exit rules are not negotiable. Transitions are validated server-side and every transition emits an audit_events row (see §13).

2.1 State definitions and matrix

Notes:

• Escalated is an overlay status. The previous "real" working state (Assigned / In Progress / Awaiting Parties) is retained in escalation_context and is the state the ticket returns to when the escalation clears or is actioned. This avoids losing officer context during an escalation spike.
• Awaiting Parties and On Hold both pause the SLA clock but differ in actor and intent: Awaiting Parties is a routine info-request block; On Hold is a deliberate, reason-bound suspension by an officer or oversight role.
• A ticket can be Cancelled/Withdrawn from most non-terminal states. The action requires a reason and emits an audit event; only Primary/Admin reps may withdraw on the company side.
• Terminal states are Closed and Cancelled/Withdrawn. The only exits from terminal states are the narrow reopen/appeal windows defined in §8.

2.2 Who can transition (high-level — full RBAC in /specs/en/04-roles-permissions/)

3. State Machine Diagram

The lifecycle below is the canonical state machine. Guards (proof-gate, sensitive approval, reopen window, etc.) are described in the relevant sections and applied on the transitions shown.

Mermaid node names cannot contain spaces, so Cancelled/Withdrawn is rendered as CancelledWithdrawn and Awaiting Parties as AwaitingParties. The on-system status enum retains the canonical names with spaces/slashes.

Written flow description. A ticket is born New on filing or inbound channel arrival. S&ITD triages it into Triaged, sets category/priority/SLA, and routes to a department section, moving it to Assigned. The assigned officer's first substantive response flips the ticket to In Progress and stops the FRT clock (the resolution clock keeps running). Work alternates between In Progress and Awaiting Parties whenever the company must supply information; each Awaiting Parties entry pauses the SLA clock and each return resumes it. Either clock breaching its SLA flips the ticket to Escalated, an overlay state that retains the prior working context and notifies the appropriate oversight tier.

When the officer has finished, they pass the proof-of-resolution gate (≥1 evidence attachment + resolution note; sensitive/VIP tickets additionally need Chair/DG approval) and the ticket becomes Resolved. From Resolved, three things can happen: the company explicitly accepts → Closed; the CSAT window (default 7 days) expires with no action → auto-Closed; or the company rejects within the window → Reopened, which re-enters the work queue at its prior working state. From Closed (or directly from Resolved) the company may also file a CPGRAMS-style Appeal within the appeal window; appeals are reviewed at the next oversight tier and either upheld (back to In Progress) or rejected (terminal Closed). On Hold is a deliberate, reason-bound suspension usable from most working states. Cancelled/Withdrawn is terminal except for a narrow withdrawn-in-error path. The only true terminal states are Closed and Cancelled/Withdrawn.

4. Filing & Triage Flow

4.1 Filing

A ticket can originate from any of the channels in module K (Multi-channel Intake): the web portal, the PWA/mobile app, an inbound email, SMS, WhatsApp message, toll-free IVR/voice transcription, or a walk-in/offline entry by an S&ITD facilitator. All channels converge on the same tickets table; the intake_channel field records origin.

Smart filing (AI-assisted):

• Category suggestion. As the company types the complaint, the AI (module E) suggests the most likely category/sub-category and routed department based on semantic similarity to past tickets and the service catalog. The filer can accept or override.
• Similar-ticket deflection. If a similar open or recently-resolved ticket exists, the portal surfaces it before submission: "You may already have an answer — see SITP-2026-LBR-000098." If the company confirms the existing ticket covers their issue, no new ticket is created (deflection tracked as analytics event). If not, filing proceeds.
• Urgency & sentiment hint. AI proposes a priority (Urgent/Normal/Low) and surfaces sentiment; S&ITD triage confirms or overrides during triage.
• PII redaction on intake. Detected PII in free-text is flagged/redacted per module E before persistence.

Draft & save-later (satisfies FR-TKT-014). A company rep can save an incomplete ticket as a draft in their personal draft store. Drafts are not visible to S&ITD or the department, do not consume a tracking ID, and have a configurable retention (default 30 days). Submitting a draft converts it to a New ticket.

Dynamic conditional intake form. The intake form is driven by the service catalog and the chosen category/sub-category. Selecting "Labour — Unpaid dues" shows different fields (last salary date, amount, employee count) than "SECP — Name reservation conflict" (proposed name, reservation number, rejection letter). Conditional sections, mandatory-field rules, and allowed attachment types are configured per category in intake_form_schema.

Tracking ID generation. On successful submission, the system allocates the next sequence number for the routed department and constructs SITP-YYYY-<DEPT>-<NNNNNN> (e.g. SITP-2026-LBR-000123). Allocation is atomic (DB transaction + row lock on the per-dept sequence). The ID is returned to the filer immediately and is the canonical reference for all subsequent communication. A confirmation is sent in the filer's preferred language (EN/UR/SD) via their preferred channel.

4.2 Triage

S&ITD triage officers see a queue of New tickets. For each, they confirm or override AI-suggested category, sub-category, priority, routed department/section, SLA definition, and sensitivity flag. They may also flag VIP (filers from priority-sector companies, large employment, foreign-investment cases) which routes through the sensitive path. Once triaged, the ticket moves to Triaged and appears in the destination department's queue.

4.3 Filing & triage flow diagram

Written description. A filer (or an inbound channel adapter) starts the flow; authenticated filers may resume a saved draft, while anonymous/whistleblower intake is restricted-visibility from the outset. The dynamic intake form is rendered based on the category selected, with AI suggesting category and destination department as the filer types. Before submission, the system runs similar-ticket deflection: if a likely duplicate or already-answered ticket exists, the filer is offered the option to not create a new ticket. If they proceed, attachments are AV-scanned and encrypted, the form is submitted, and a tracking ID is atomically allocated in the SITP-YYYY-<DEPT>-<NNNNNN> format. The ticket enters New and lands in the S&ITD triage queue, where a triage officer confirms or overrides category, priority, SLA, destination, and sensitivity. On confirmation the ticket becomes Triaged, enters the destination department's section queue, and is assigned to an officer — either by the section head or by the AI auto-router — moving to Assigned.

5. SLA Model

5.1 SLA definitions

Every ticket is bound to exactly one row in sla_definitions, selected at triage by (department, category, priority). Each row carries two timers:

• First Response Time (FRT) — from creation to the first substantive response from the assigned department (the response that flips the ticket Assigned → In Progress). Acknowledgements, "we are looking into this", and automated receipts do not satisfy FRT.
• Resolution Time — from creation to proof-gated Resolved.

Default targets (overridable per department/category):

"Business day" is computed in the destination department's business hours and timezone (default Asia/Karachi, PKT) after removing Sindh public holidays and weekends. The defaults are overridable in sla_definitions per (department, category, priority); a NULL resolution time on a row means "no resolution SLA" (advisory only — used for open-ended categories like RTI where statutory deadlines apply instead).

5.2 SLA clock — when it runs, pauses, resumes

The SLA clock is a monotonic counter of business time accumulated against each timer. Two independent clocks run per ticket: the FRT clock and the Resolution clock. Both share the same run/pause rules below, except that the FRT clock stops permanently once FRT is met.

Clock runs when status is any of: New, Triaged, Assigned, In Progress, Reopened, Appealed (during active review), Escalated (overlay — runs against the retained working state).

Clock pauses when:

1. Status is Awaiting Parties (company or third-party response outstanding).
2. Status is On Hold (reason-bound deliberate pause).
3. The current wall-clock time is outside the department's configured business hours (default Mon–Fri 09:00–17:00 PKT; configurable per department in dept_business_hours).
4. The current wall-clock date is a Sindh public holiday listed in holiday_calendar.
5. The current wall-clock date is a weekend for that department (default Sat + Sun; configurable — some departments work Saturdays).

Clock resumes when:

• Company responds (status returns Awaiting Parties → In Progress), or
• On Hold is lifted by an authorised actor, and
• The current wall-clock time is within business hours on a non-holiday, non-weekend day.

If a resume event happens outside business hours, the clock resumes at the start of the next business hour. The elapsed counter is persisted on every state transition so a server restart never loses SLA state.

Near-breach and breach. The SLA engine evaluates each open ticket's elapsed time against its timers on every tick (default 1-minute cron + on-transition). At configurable thresholds (default: 80% of timer = near-breach warning, 100% = breach), the engine emits audit_events and triggers the notification matrix (§12) and the escalation ladder (§6).

5.3 SLA clock diagram

Written description. The SLA clock accumulates business time only — never nights, weekends, or Sindh public holidays — and only while the ticket is in a "department is responsible" state (New, Triaged, Assigned, In Progress, Reopened, Appealed-under-review, or Escalated against a working-state context). Any transition into Awaiting Parties or On Hold pauses the clock; the corresponding transition back to In Progress resumes it, but only if wall-clock time is inside the destination department's business hours on a non-holiday weekday. The FRT clock stops permanently when the first substantive response satisfies FRT, while the resolution clock continues running until proof-gated Resolved. Near-breach (default 80% of a timer) and breach (100%) thresholds emit audit events and drive the escalation ladder; the running clock keeps accumulating even past breach so the breach duration is measurable.

5.4 Business hours & holiday calendar

• dept_business_hours: per-department rows of (weekday, open_time, close_time, timezone). Default for all departments: Mon–Fri 09:00–17:00 Asia/Karachi. Departments that work Saturdays or have shifted hours configure their own rows.
• holiday_calendar: Sindh Government public holidays, sourced and updated by S&ITD annually (Eid ul Fitr, Eid ul Adha, 9th/10th/11th Muharram, 12th Rabi ul Awwal, Pakistan Day, Independence Day, Iqbal Day, Labour Day, Eid Milad un Nabi, Ashura, Chehlum, and any notified occasional holidays). Hijri-date holidays are computed against the Islamic calendar and resolved to Gregorian dates each year; both calendars are shown in the UI per §2 of _context.md.
• RTI statutory deadlines. For tickets categorised as RTI (Sindh Transparency & RTI Act 2016), the statutory deadlines (default 10 working days, extendable by 10) take precedence over the table above and are configured as a separate SLA row marked statutory = true.

6. Escalation Ladder

6.1 Ladder structure

When a ticket's resolution SLA breaches and remains unresolved, it climbs a configurable oversight ladder. The default ladder (locked decision, overridable per department/category in escalation_ladders) is:

The same ladder applies inside S&ITD itself — S&ITD is both facilitator and a department with its own tickets (e.g. against its own sections), so an S&ITD-internal ticket escalates from S&ITD Section Officer → S&ITD Additional/Joint DG → S&ITD Secretary → SACM. Triggers and tiers are configurable per escalation_ladders row scoped to (department, category).

Triggers are anchored to the SLA. Concretely, the +2/+5/+10 counts are business days after resolution-SLA breach, not after creation. A ticket that resolves within its SLA never escalates. A ticket that breaches climbs one tier at each configured interval until resolved or force-closed by an oversight actor with action powers.

6.2 Configurable oversight powers

Each oversight tier is configured per department as either notify-only or action. The configuration lives in oversight_powers keyed by (department, tier).

Symbols per _conventions.md §8: ✓ allow · ✗ deny · ◐ conditional/configurable.

The default policy is: tiers 1 (DG) and 2 (Secretary) are action, tier 3 (Minister/SACM) is notify + directive; this is overridable per department. Sensitive/VIP closure approval always rests with Chair/DG regardless of tier.

6.3 Alerts and audit

• Near-breach alert (80% of any timer, configurable): notify assigned officer + section head + watchers via email/in-app; SMS if configured.
• Breach alert (100% of any timer): notify officer + section head + watchers + the next oversight tier via email/in-app/SMS; WhatsApp for tier ≥ 2.
• Each escalation event writes an immutable row to audit_events (type = escalation, actor = system or actor = oversight-user, tier, reason, timestamp) and a corresponding ticket_history entry. The ticket's status flips to Escalated while escalation_context retains the prior working state.
• Repeat-escalation handling. If a ticket is de-escalated (e.g. resumed to In Progress) and then breaches again, it re-enters the ladder at the tier it left (never resetting to tier 1) unless an oversight actor with action powers explicitly resets it. Each repeat-escalation increments an escalation_count and a repeat_offender flag on the ticket and on the assigned officer/section, surfacing in analytics (module I) for systemic-issue detection.

6.4 Escalation sequence diagram

Written description. The SLA engine detects breach and immediately flips the ticket to Escalated, writing a breach event plus the tier-1 escalation event to audit_events and notifying the officer, section head, and the department's DG, who is added as a watcher. After 2 more unresolved business days, the engine escalates to tier 2 (Secretary), with email/in-app/SMS/WhatsApp delivery and watcher addition. After 5 more unresolved business days, it escalates to tier 3 (SACM and S&ITD Secretary), triggering a formal directive letter in addition to the standard channels. At each tier, if the configuration grants action powers, the oversight actor can reassign, override the SLA, force-resolve, or issue a binding directive — each of which is itself audited. If the tier is notify-only, the ticket remains Escalated until the working officer submits a proof-gated resolution, at which point the engine logs the de-escalation and moves the ticket to Resolved or back to its prior working state.

7. Proof-of-Resolution Gate

7.1 The gate

A ticket cannot transition to Resolved until all of the following hold:

1. ≥1 evidence attachment is present on the ticket (filed under evidence category, AV-scanned, encrypted — module D). Acceptable evidence types are configured per category in evidence_schema (e.g. signed settlement, payment proof, corrected licence, NOC, official letter).
2. A resolution note is submitted by the assigned officer describing what was done, with reference to the attached evidence.
3. Sensitive/VIP tickets only: explicit Chair/DG approval of the proposed resolution before the transition is allowed (see §7.3).
4. Inter-departmental tickets: every linked sub-task/department must individually mark itself resolved (or be explicitly waived by the lead department).

The gate is enforced server-side on the PATCH /tickets/:id/status transition; the API returns 409 Conflict with a structured error if any precondition fails. The UI disables the "Resolve" action until preconditions are met.

7.2 Auto-close logic

Once Resolved, the ticket enters the CSAT window (default 7 calendar days, configurable globally and per department in csat_config). During this window:

• The company is invited to (a) accept the resolution, (b) rate it via CSAT (1–5 stars + optional free-text), or (c) reopen with a reason.
• Auto-close triggers when either the company explicitly accepts, or the CSAT window elapses with no action. On auto-close the ticket moves to Closed (terminal) and a closure notice is sent.
• If the company submits a poor CSAT rating (default ≤ 2 stars), the system enables the appeal path (§8) and surfaces it in the company's UI.
• If the company explicitly rejects within the window, the ticket moves to Reopened and re-enters the work queue.

7.3 Sensitive / VIP closure approval

For tickets flagged sensitive = true (legal/political exposure, VIP filer, foreign-investment, mass-incident) or vip = true, the proof gate adds a fourth precondition: a Chair or DG approval must be recorded on the proposed resolution before Resolved is allowed. The assigned officer submits the resolution package (evidence + note); it routes to the department's Chair/DG approval queue; on approval the gate opens and the officer can flip to Resolved. Rejection returns the ticket to In Progress with the Chair/DG's reason attached. The approval is itself an audited event with actor, timestamp, and decision.

7.4 Proof-of-Resolution gate diagram

Written description. From In Progress the officer marks the ticket ready to resolve and the proof gate evaluates: at least one evidence attachment and a resolution note must exist, otherwise the transition is blocked with 409 Conflict and the ticket stays in In Progress. For sensitive/VIP tickets the package additionally routes to the Chair/DG approval queue; approval opens the gate while rejection returns the ticket to In Progress with a recorded reason. With the gate cleared the ticket becomes Resolved and the CSAT window starts (default 7 calendar days). The company can accept, rate, or reject; an explicit accept or window expiry triggers auto-close to terminal Closed, while a rejection moves the ticket to Reopened. A poor CSAT rating (default ≤ 2) enables the appeal path; if the company files an appeal within the window the ticket moves to Appealed, otherwise it closes on window expiry.

8. Reopen & Appeal

8.1 Reopen

Within the reopen window (default = the CSAT window; configurable in csat_config), the company rep (Primary/Admin, or Filer if permitted by the Primary) can reopen a Resolved or Closed ticket by providing a reason. Reopen returns the ticket to its previous working state (typically In Progress) and restarts the resolution clock for a configurable additional SLA (default = 50% of the original resolution SLA, capped). Reopens are capped per ticket (default 2) to prevent abuse; exceeding the cap forces the company down the appeal path instead. Each reopen is an audited event.

8.2 Appeal (CPGRAMS-style second chance)

Beyond reopen, the company may file a formal appeal against a Resolved or Closed ticket within the appeal window (default 30 calendar days from closure, configurable). The appeal asks a higher authority to review whether the resolution was adequate. Appeals are routed to the next oversight tier above the one that closed the ticket: if the ticket was closed at working level, the DG reviews; if closed under DG purview, the Secretary reviews; if closed under Secretary purview, the SACM/S&ITD Secretary reviews. A poor CSAT rating (≤ threshold) enables and pre-fills the appeal form and extends the appeal window by a configurable grace (default +15 days).

The reviewing authority can:

• Uphold the appeal → ticket returns to In Progress (reopened for proper resolution) with a directive to the section.
• Reject the appeal → ticket stays Closed (terminal); the rejection letter is generated (module L) with QR verification and sent to the company.
• Partially uphold → specific action items added as sub-tasks, ticket returns to In Progress for those items only.
• Re-route → ticket moves to Triaged for assignment to a different section/department.

Each appeal decision is audited with actor, tier, reasoning, and resulting action.

8.3 Reopen & appeal diagram

Written description. From Resolved or Closed the company has two paths inside their respective windows. The reopen path (default window = the CSAT window) accepts a reason from the company and, subject to a per-ticket reopen cap (default 2), returns the ticket to its prior In Progress state with a reduced resolution SLA (default 50% of the original). When the reopen cap is exceeded the company is forced onto the appeal path. The appeal path (default 30-day window from closure, extendable by a poor-CSAT grace) routes the case to the next oversight tier above the one that closed it. The reviewing authority may uphold (ticket returns to In Progress with a directive), partially uphold (sub-tasks created, ticket returns to In Progress for those items), reject (closure is final; a QR-verified rejection letter is generated), or re-route (ticket moves to Triaged for a different section). All decisions are audited.

9. TRI (Tripartite) Meeting Flow

9.1 When TRI is used

A TRI (Tripartite Review) meeting is triggered when normal ticket progress stalls. Any of the following can request one:

• The company rep ("Request TRI meeting" action on the ticket).
• The assigned department officer or section head.
• The S&ITD facilitator.
• Auto-triggered by the SLA engine when a ticket has been Escalated at tier ≥ 2 with no movement for a configurable interval (default 3 business days).

A TRI request moves the ticket to On Hold (clock paused) with reason "TRI meeting requested" and creates a meetings record of type TRI linked to the ticket.

9.2 Parties and modality

The three required parties are:

1. Company — Primary Authorized Rep (or delegate), optionally with counsel/technical staff.
2. S&ITD — the assigned facilitator, who chairs the meeting.
3. Concerned Department(s) — the assigned officer plus the section head; for multi-department tickets, all concerned departments.

Modality is configurable per meeting: physical (at the department or S&ITD office), virtual (Zoom / Google Meet / Microsoft Teams — the provider is selectable per meeting from the configured connectors), or hybrid. Recording consent is captured before any recording starts and is logged in meeting_consent.

9.3 Agenda auto-drafting

On TRI creation the AI (module E) auto-drafts an agenda from the ticket's full history — title, description, all messages, attachments, SLA events, prior escalations, and any related tickets — and proposes discussion items, decision points, and a recommended order. The facilitator reviews and edits the agenda before sending invitations. The agenda is multilingual (EN/UR/SD) per participant preference.

9.4 Outcome

At meeting end the facilitator records the outcome as one of:

• Resolved — agreement reached; the ticket returns to In Progress only long enough to attach the agreed evidence, then moves to Resolved (proof gate still applies — typically the MoM + signed agreement serve as evidence).
• Further action items — specific owners and due dates recorded; these become sub-tasks (§11) and the ticket returns to In Progress.
• Escalate — the meeting could not resolve the issue; the ticket moves to Escalated at the next tier with the meeting record as supporting context.

In all cases a MoM is produced (§10) and permanently attached to the ticket.

9.5 TRI flow diagram

Written description. When a ticket stalls or sits at escalation tier 2+ without movement, any of the company, the officer, the facilitator, or the auto-trigger can request a TRI meeting. The request creates a meetings record and parks the ticket in On Hold with reason "TRI meeting requested", pausing the SLA clock. The AI auto-drafts an agenda from the ticket's full history and uploads, which the facilitator reviews and edits. The modality — physical, virtual (Zoom/Meet/Teams), or hybrid — is selected per meeting, invites go out multilingually, and recording consent is captured. After the meeting, the facilitator records the outcome: a fully-resolved case returns to In Progress only long enough to attach the MoM and signed agreement as proof-gate evidence, then moves to Resolved; a partial outcome creates sub-tasks with owners and due dates and the ticket returns to In Progress; a failure to agree escalates the ticket to the next tier with the meeting record attached. In every case a MoM is produced and attached per §10.

10. MoM (Minutes of Meeting) Flow

The MoM flow applies to any meeting attached to a ticket — a TRI (§9), a direct company–department meeting, or any other recorded meeting. The department preparing the MoM uploads its own format (PDF, Word, or images of a signed paper MoM); manual entry and AI live-transcription are available as feature-flagged alternatives but upload-first is the default and primary path per _context.md §5.

10.1 Upload → scan → store → enrich

1. Prepare & upload. The department's officer or the S&ITD facilitator prepares the MoM in the department's own template and uploads it (PDF/DOCX/PNG/JPEG). Multiple files allowed.
2. AV scan. ClamAV scans every upload; infected files are quarantined and the upload is rejected with a reason.
3. Store. Clean files are encrypted and stored in object storage (MinIO); a mom_documents row is created linking the file to the meetings record and the parent ticket.
4. OCR (if scanned). Image-only or scanned PDFs are routed through the pluggable OCR engine (Tesseract on-prem / Google Document AI / Azure Document Intelligence / AWS Textract). OCR supports multilingual text (English + Urdu + Sindhi, including Nastaliq and Naskh scripts) and produces a searchable text layer.
5. AI extraction. The AI service (module E) reads the OCR text (or native text for born-digital files) and extracts:
   • A structured summary of the meeting.
   • Action items with owner, due date, priority, and dependency.
   • Decisions recorded.
   • Attendees (cross-referenced with the invitee list).
   • A machine translation to EN/UR/SD so participants can read the MoM in their preferred language.
6. Officer review & confirm. The uploading officer reviews the extracted action items in a side-by-side view (original document ↔ extracted table), corrects any mis-extraction, and confirms. Confirmed action items become sub-tasks on the parent ticket (§11), each with its own owner, due date, and SLA slice.

10.2 Approval gate

• Normal ticket: the uploader publishes directly. No approval required.
• Sensitive / VIP ticket: the MoM must pass Chair/DG approval before it can be published/shared. The MoM enters the approval queue; on approval it is publishable, on rejection it returns to the uploader with the reviewer's reason.

10.3 Publish & share

On publish:

• The MoM is permanently attached to the ticket (versioned — every revision creates a new mom_documents version row; prior versions are retained and audit-logged, never overwritten).
• The MoM is auto-shared to all participants (company reps, S&ITD facilitator, department attendees, oversight watchers) via:
  • Email with the MoM attached (or a secure download link).
  • In-app notification with deep-link to the ticket.
  • SMS / WhatsApp short summary + link (per participant preference).
• Acknowledgment tracking: each participant's acknowledgment (open, download, explicit ack) is recorded against the MoM and shown in the ticket timeline. Non-acknowledgment past a configurable grace (default 3 days) triggers a reminder.
• The MoM is cross-posted to NITB e-Office if the e-Office integration is enabled for that department (module H), creating the corresponding official file movement.

10.4 MoM flow diagram

Written description. After any meeting, the responsible officer uploads the MoM in the department's own format (PDF, Word, or images of a signed paper document). Every upload is ClamAV-scanned; clean files are encrypted and stored as a mom_documents row linked to the meeting and parent ticket. Scanned documents run through the pluggable multilingual OCR engine (English, Urdu including Nastaliq, and Sindhi including Naskh) to produce a text layer; born-digital files skip OCR. The AI service then extracts a summary, structured action items with owners and due dates, recorded decisions, and attendee list, and produces machine translations in all three languages. The uploading officer reviews the extraction side-by-side with the original and confirms; confirmed action items become sub-tasks on the ticket. For normal tickets the officer publishes directly; for sensitive/VIP tickets the MoM must first pass Chair/DG approval. On publish the MoM is versioned and permanently attached (immutable, prior versions retained), auto-shared to all participants across email, in-app, and SMS/WhatsApp per their preferences, with acknowledgments tracked and reminders sent after a grace period. If the department has e-Office integration enabled, the MoM is cross-posted to NITB e-Office as an official file movement.

11. Multi-Department Coordination

11.1 Referral and parallel routing

A single ticket can involve multiple departments. Two routing modes are supported and may be combined:

• Sequential referral — the lead department resolves its part then refers the ticket onward (e.g. SECP refers to FBR for NTN correction). The ticket's working state is preserved per department; SLA clocks pause for the referring department while waiting for the next.
• Parallel routing — one ticket is worked by multiple departments concurrently, each with its own sub-task and its own SLA slice. The parent ticket cannot reach Resolved until all sub-tasks are resolved or explicitly waived by the lead department (proof gate precondition §7.1).

Each routed department gets its own assignment, its own SLA row from sla_definitions, and its own escalation ladder from escalation_ladders. The S&ITD facilitator has cross-department visibility and can rebalance, merge, or split at any time.

11.2 Sub-tasks

A sub-task is a fully-fledged ticket linked via parent_ticket_id. Sub-tasks inherit category, priority, and SLA from the parent by default but can be overridden. Sub-tasks have their own status lifecycle (§2), their own SLA clocks, and their own escalation ladders. Sub-tasks created from MoM action items (§10) carry origin = mom_action_item with a reference back to the MoM. The parent ticket's resolution is gated on all mandatory sub-tasks being resolved.

11.3 Link / relate / merge / split

11.4 Bulk actions

Authorised actors (Facilitator, Section Head, DG/Secretary with action powers) can perform bulk operations on a filtered selection of tickets: bulk assign, bulk re-route, bulk pause (On Hold), bulk merge, bulk close (with reason), bulk add watcher, bulk export. Every bulk action is logged once per affected ticket in audit_events with the bulk-action ID for traceability.

11.5 Multi-department coordination diagram

Written description. A parent ticket can be routed by the S&ITD facilitator either sequentially (a referral chain through SECP → FBR → SRB, with each department's SLA clock running only during its turn) or in parallel (concurrent sub-tasks, each with its own SLA and escalation ladder, all of which must be resolved before the parent can pass the proof gate). Sub-tasks are full tickets linked by parent_ticket_id; those originating from MoM action items are tagged accordingly. Linking/relating connects two independent tickets without merging their lifecycles; merging folds duplicates into a canonical ticket and cancels the others with full history preservation; splitting creates fresh tracking IDs for distinct issues raised in one filing. Watchers and CC add observers without changing assignment. Bulk actions let authorised actors apply changes across filtered selections, with every affected ticket individually audited under a shared bulk-action ID.

12. Notifications at Each Transition

The Notification Service (module G) emits templated, multilingual notifications on every audited transition. Each notification's language is the recipient's preferred language; each channel honours the recipient's preference centre (digests, quiet hours, channel opt-in). Two-way inbound replies — a reply to the notification email or WhatsApp — are parsed and appended to the ticket as an inbound message, with the original notification referenced for threading.

All templates are versioned and editable by Super Admin (per language). Each sent notification is itself logged in notifications with template ID, language, channel, recipient, and delivery status, and is retained for audit.

13. Audit & Traceability

Every state change, escalation, pause, resume, approval, publish, merge, split, bulk action, and notification is recorded immutably in two complementary stores (data model in /specs/en/05-data-model/):

• ticket_history — the human-readable, ticket-scoped timeline. One row per transition with ticket_id, from_status, to_status, actor_id, actor_role, timestamp, reason, and a diff of changed fields.
• audit_events — the system-scoped, append-only event log. One row per auditable action with event_type (state_change, escalation, sla_pause, sla_resume, sla_override, approval_decision, mom_publish, merge, split, bulk_action, notification_sent, …), actor_id, actor_role, target_type, target_id, payload (JSON), ip, user_agent, timestamp, and an optional reason.

Rows in both tables are append-only; no UPDATE or DELETE is permitted at the application or DB-role level (enforced via MariaDB grants — see /specs/en/11-security-compliance/). A separate retention/archival job moves aged rows to cold storage per Sindh Archives rules (§6 of _context.md) without deleting them.

Each audit_events row is cross-referenced:

• To the originating ticket_history row via a shared correlation_id.
• To any notification sent (§12) via notifications.audit_event_id.
• To any file or MoM involved via payload.file_ids / payload.mom_id.

This gives end-to-end traceability from "company filed at T0" through every triage, pause, escalation, approval, MoM publish, and closure — satisfying both internal governance review and external audit (RTI, Auditor General, CERT-PK).

14. Edge Cases

15. Configurability Summary

The system is designed so that almost every behavioural parameter is configurable, either globally (S&ITD-wide) or per department/category. The matrix below summarises what is configurable and where it lives. Cells marked ◐ are conditional (configurable where indicated).

Configuration governance. All configuration tables are themselves audited: any change to a sla_definitions, escalation_ladders, oversight_powers, dept_business_hours, holiday_calendar, csat_config, appeal_config, tri_config, mom_config, or feature_flags row writes an audit_events entry with the old and new value, the actor, and a mandatory change-reason. Configuration changes are restricted to Super Admin (S&ITD) for global rows and to the department's DG/Secretary (with action powers) for department-scoped rows. Sensitive global changes (e.g. disabling the proof gate) require two-person approval.

End of document.