The operating core of the programme
Seat System, Allocation & Booking
The service-seat definition, six-state lifecycle, fourteen-step publication workflow, eight-stage university booking process, allocation criteria with safeguards, and the seat-approval authority options.
What a service seat is
A service seat is an approved opportunity for one eligible student to perform an identified set of government service activities, during a defined service period, at a particular institution or facility. Every seat carries a full specification: seat ID, receiving organization and facility, sector and department, requested/approved/booked/confirmed/remaining counts, service period, expected workload, required disciplines and skills, eligibility criteria, student responsibilities, expected outputs, required training, workplace coordinator, safety conditions, data-access restrictions, accessibility arrangements, location and travel requirements, remote-work permissions, cost implications for the university, and approval/publication status.
The seat is the atomic unit of the entire programme: government supply is measured in seats, university demand is expressed as seat requests, allocation decisions distribute seats, bookings consume them, and capacity planning validates them. Getting its lifecycle right is getting the programme right.
Seat lifecycle — six states
The master rule: a seat is not filled merely because a university requested it. The platform tracks six states with strictly controlled transitions:
| State | Meaning | Who controls the transition | Platform enforcement |
|---|---|---|---|
| 1 · Requested | A government office proposes N seats with a full specification | Receiving office | Duplicate and conflict detection across the organization; incomplete specifications rejected |
| 2 · Approved | Competent authority validates capacity and approves ≤ requested number | Seat-approval authority (see options below) | Approval never exceeds validated capacity; reasons recorded |
| 3 · Published | The seat becomes visible to eligible universities | Approval authority | Publication snapshot versioned; changes auditable |
| 4 · Provisionally booked | A university nominates a student against the seat | University coordinator | Eligibility validation (identity, enrollment, stage, prior completion, conflicts) before nomination accepted |
| 5 · Confirmed | Receiving office confirms the student; placement becomes active | Receiving-office coordinator | Confirmation SLA; expiry returns the seat to published |
| 6 · Completed | Service delivered and verified; completion recorded | Triangulated: office + university + platform | Unique constraint — one active booking and one completion per student per degree level |
How government institutions publish seats
The publication workflow runs through the Government Institution Portal in fourteen steps:
Hard rules: a facility cannot publish more seats than its approved capacity; the platform prevents duplicate seat requests and conflicting allocations across the same organization; all changes are versioned and auditable.
How universities apply and receive allocations
Universities — never individual students acting alone — apply for seats. The University Portal supports the request with: placement cycle, number of eligible students by discipline and degree level, preferred sectors and locations, requested service periods, student qualifications, accessibility requirements, available university funding, and requested seats by category. Each request is tracked separately, and the allocation authority records requested / approved / rejected / deferred counts with reasons for every decision.
The eight-stage booking workflow
Student-facing portal functions (view eligibility, express preferences, accept/decline under rules, view assignments and records, submit complaints, obtain certificates) are specified on the Digital Platform page — students can never alter official bookings, allocations, attendance or completion outcomes.
Allocation criteria and fairness rules
The allocation algorithm follows published rules, never unexplained automated decisions. Recommended criteria with illustrative weights (configurable by the steering committee, published before each cycle):
| Criterion | Weight (illustrative) | Measure | Abuse safeguard |
|---|---|---|---|
| Verified student demand | 25% | Eligible students by discipline vs requested seats | Demand verified against enrollment records, not self-declared |
| Discipline match | 20% | Programme-to-seat discipline fit | Match computed from the verified program inventory |
| Geographic distribution | 15% | District-level seat demand vs supply | Prevents Dhaka-concentration; supports near-home placement |
| Equity across universities | 15% | Fair share for smaller and newer institutions | Floor allocations for eligible small universities |
| Past utilization & performance | 15% | Seats used vs allocated in prior cycles | Hoarding detection; unused seats released mid-cycle |
| Readiness (funding, coordinators) | 10% | Verified university preparedness | Readiness data published; deferral reasons recorded |
Edge-case handling is specified in the matching model: oversubscription, undersubscription, students who receive no placement (the guaranteed-placement rule), cancellations, and receiving offices that withdraw seats.
Who approves seats — three options
Each ministry approves seats for its own departments and facilities. Closest to existing business rules; risks 43 inconsistent approval practices and weak cross-sector visibility.
One office approves all seats. Maximum consistency and data quality; risks bottleneck and detachment from sectoral realities.
Central office sets standards, validates capacity and audits; sectoral focal points approve within standards. Balances consistency with sectoral knowledge; mirrors the governance structure.
The recommendation follows the governance analysis (CSV 23, PH-0 design task); the final choice belongs to the steering committee and, for the compulsory scope, the statute.