Digitising third-party monitoring of NAVTTC-funded training partner institutes — field capture on a phone, server-side audit trail, and a submission package that survives scrutiny by the Director (M&E).
NAVTTC commissions independent third-party firms to inspect the private institutes delivering its funded training. Server4Sale holds that mandate for the PMYSDP Skills of Tomorrow (Batch-I) programme under work order F.139/2025-26/Proc-S4S-SOT-B1. This portal is the instrument that turns a field visit into a defensible, payable claim.
Officers complete a printed NAVTTC form at the institute, then it is transcribed, reviewed, approved and packaged for NAVTTC HQ. Every hand-off is a place for data loss, delay and error — against a five-day approval clock with penalties attached.
The same form, captured on the officer's phone at the institute: per-course/per-shift scope, evidence photographed at the point of observation, and incremental server-side autosave that survives a dropped connection. One record, from the visit through to the report.
NAVTTC's own SOP places QA and completeness responsibility on the firm, and states the M&E Section is not expected to complete missing documentation or perform basic quality assurance. The portal is therefore built to make the firm's own record provable, not merely quick.
The full monitoring lifecycle as NAVTTC specifies it, and where the portal acts at each stage. Stages 1, 2, 4 and 6 are governed by the official commencement SOP of 12 October 2026; stages 3 and 5 are the firm's internal controls. Items marked immediate reporting are conditions NAVTTC requires reported without delay.
The official form is a printed form completed at the institute. The portal accepts the same form either way, and records which way it was captured, so that a reviewer and NAVTTC can tell a contemporaneous record from a transcription.
The officer has connectivity at the institute and completes the form on the phone as the visit happens.
The officer has no connectivity at the institute, completes the printed form by hand, and enters it into the portal afterwards.
| Aspect | Live capture | Paper and transcribe |
|---|---|---|
| Original record | The portal entry, with its evidence files | The scanned paper form; the portal entry is the transcription of it |
| Marker | Captured live | Transcribed from paper form — shown in the report, the packet and the audit trail |
| Attestation | Field declaration that observed facts and missing items are recorded honestly | Field declaration, plus the transcription date, transcribing officer and paper accession id |
| Before approval | Supervisor review, then independent programme approval | Same, and the transcription is compared against the uploaded paper original |
| Evidence | Photos uploaded as taken | Photos imported afterwards; every category must still be met |
| Validation | Identical. Both modes write to the same visit, the same scopes, the same evidence rules and the same approval chain; the mode is the only difference. | |
In paper mode the officer prints the form for each assigned visit before travelling. Identity fields are pre-filled so the wrong institute cannot be transcribed; observational fields are left blank for completion at the institute; and the accession strip travels with the form so it can be matched back to its visit.
Institute code, name, address, district, package, trade codes, batch and capacity reference are filled from the visit record. Everything observational is blank.
Visit accession id, visit id, officer name and the criteria and form version in force on the visit date.
The completed form is scanned and uploaded, and the portal entry is compared against it before approval.
Taken from the 16 October 2026 work order and the programme's normalised operational data. All six trades are categorised in the source as High-End (Industrial).
| Code | Trade | Category | Tools list source |
|---|---|---|---|
| 820 | AI Powered eCommerce | High-End (Industrial) | Not in the standard manual |
| 819 | AI for Everyone | High-End (Industrial) | Partial — no trade list |
| 43 | Multimedia and Graphic Designing | High-End (Industrial) | Partial — no trade list |
| 821 | Earning Money Through Freelancing | High-End (Industrial) | Not in the standard manual |
| 615 | Digital Marketing & Search Engine Optimization (SEO) | High-End (Industrial) | Not in the standard manual |
| 818 | AI Financial Analyst with Power BI | High-End (Industrial) | Partial — no trade list |
| Scope | Detail |
|---|---|
| Programme | PMYSDP Skills of Tomorrow (Batch-I) — Sindh |
| Work order | F.139/2025-26/Proc-S4S-SOT-B1, dated 16 October 2026, M/S Server4Sale |
| Package-08 | 37 institutes across 13 districts |
| Package-09 | 44 institutes across 7 districts |
| Total | 81 institutes across 20 districts |
| Held separately | 9 institute records, not active allocations — no release authority is established |
| Batches | 136 trade/batch records |
The full institute list with addresses, districts, package, trades and batches is operational portfolio data and is not published on this page.
Absent for all 136 batches. The printed form's start date, end date and class timings columns are blank in the source institute forms as well, so this is a gap in the source data rather than a parsing failure. Dates appearing inside timing text are not treated as course start dates.
The source supplies a selected-candidate count. That is a source aggregate and is not treated as approved
capacity or as attendance. approved_capacity remains null until authority evidence exists.
All 90 institute and campus identities need confirmation against an authoritative list. The importer deliberately refuses to guess, split or merge campuses by name or address, and a missing source id stays flagged for reviewed identity resolution.
Eighteen unique timing exceptions — seven missing and eleven with conflicting dates embedded in the timing text. Parsed times remain unverified schedules, and conflicting rows are held outside the actionable schedule rather than being filled with a default.
The existing portal is not a prototype. It is a working, tested application — and the plan is to extend it, not replace it. The table below is the verified result of running its own suites locally against a real MariaDB instance, not a summary of a status report.
883 assertions, zero failures — against a real database, not mocks.
Including a 390 px officer viewport, offline reconnection and conflict handling.
Staging, independent approval, interrupted apply, and compensating rollback.
Source files hash-verified across both handover packages.
| Area | What it does | Status |
|---|---|---|
| Access control | Four roles — admin, supervisor, field officer, programme reviewer. Programme membership, assignment checks and self-review prevention are enforced server-side, not in the interface. | Verified |
| Field capture | Per-course / batch / group / shift / session scope, with each scope holding its own attendance, equipment, people and evidence. Incremental autosave with optimistic revision checks. | Verified |
| Evidence | Private originals, SHA-256 verification, duplicate detection, quarantined until a malware scan clears. Nothing in quarantine can count as clean evidence or enter a packet. | Verified |
| Review & approval | Submit → review → return with explained correction → independent internal approval → frozen PDF snapshot. Later edits invalidate the current approval without deleting history. | Verified |
| Master-data import | Staged CSV/XLSX with exact column mapping, full dry run, independent hash-bound approval, transactional idempotent apply, and reviewed compensating rollback that blocks blind reversal. | Verified |
| Schedules | Generated plan → independent review → recorded manual submission → recorded acknowledgement, kept as four distinct states. Nothing is emailed automatically. | Verified |
| Audit | Immutable event trail plus idempotency receipts, so a replayed request cannot duplicate an action and a superseded record remains readable. | Verified |
| Official scoring | Both historical scoring workbooks are transcribed with formulas and conflicts preserved, but no rubric is activated: the applicable programme profile and several scoring boundaries are unresolved by the source. | Blocked on authority |
| Official submission | NAVTTC's M&E App has no integration. The portal produces the submission package; a person enters it in NAVTTC's system. | External limit |
On a phone, the officer currently lands on the desktop console — report filters and programme fields — before reaching a visit, and the form itself renders inside a frame. The form is sound; the way it is reached is not.
Infrastructure and photographic evidence are asked once per visit on the official form, but the model collects them per scope — once per inspected course or session. For a two-trade institute that turns a single set of answers and photographs into two. A separate set of hardcoded checks also overlaps the official question set, so some questions are asked twice in two vocabularies.
Device-side recovery is disabled in the shipped default. An edit made in a basement classroom with no signal is lost when the tab closes, because it never left the browser. For a field instrument, that is the most damaging failure available.
Without a scanner, uploads stay quarantined and packets stay blocked — so no visit can actually be completed. This is an environment requirement, not an application change.
The standard manual in the handover is written for commercial-based-training trades. It carries no tools list for AI Powered eCommerce, Earning Money Through Freelancing, or Digital Marketing & SEO, and no usable list for AI for Everyone or AI Financial Analyst with Power BI. The equipment check therefore has no sourced list to work from for any of the six.
Six phases, sequenced so that the highest-risk unknowns surface earliest. Phases 0 and 1 are engineering. Phases 2 to 5 each contain a gate that only the firm or NAVTTC can open — no amount of code substitutes for them.
Consolidate both handover packages, verify every artifact by hash, and stand up the application on the target host without disturbing the other services sharing it.
The deliverable: a phone-first capture surface that officers actually use in an institute, with no desktop console in the way.
Make the data model match the official form's own structure, and make every rule cite the source it comes from.
Support the printed form as a first-class route into the portal, alongside live capture on the phone.
Staged through the existing reviewed import — never a direct production write.
Build the engine, keep it switched off until the rubric is authoritative.
Turn completed visits into the packet NAVTTC expects, and into a claim that survives verification.
The handover is deliberately explicit about the difference between a fact and a gap. These are the ones that shape the build, stated the same way.
Each item below has a technical answer ready. What is missing is authority, not engineering — and none of them blocks the Phase 1 field build, which can proceed in parallel.