Selected work / NIRANTAR
Quality assurance · Evidence governance · Audit · Working prototype
Naming what a return can prove
A continuous quality-assurance system for NAAC accreditation — built on Karnavati University’s own published record.
Real evidence. Named as real.
Twenty-six sub-criteria. Five years of scattered records. One line an institution cannot let blur.
The problem
NAAC accreditation asks an institution to prove itself against sub-criteria it did not write, using a five-year record scattered across departments, spreadsheets and hallway folders. The distinction that actually matters — a figure already submitted and verifiable, a projection standing in for a year still under way, and a result nobody may claim before the framework publishes its thresholds — usually collapses into one undifferentiated return that a validator either trusts or doesn’t. NIRANTAR keeps the three kinds of number apart on every screen that shows them.
My contribution
Sole authorship, built from the university’s own published NAAC record. Twenty-one modules over one evidence ledger — Command Centre, AQAR Composer, Reconciliation, Metric Ledger, Evidence Vault, Assurance Engine and more — directed through an AI-assisted build, then independently audited against every requirement raised during the engagement.
Deliverables
- Twenty-one module working prototype over one evidence ledger
- AQAR templates for every NAAC criterion — 256 files, metric-numbered
- Independent audit report — 69 requirements, verdicts and evidence
- System map and master documentation
- Seven role-scoped accounts on one shared dataset
Process
Decisions that shaped it
Separate real, illustrative and refused.
124 metric definitions and seventy submitted values come from the institution’s own record. The current year’s completion figures are illustrative until the year closes, and every screen that shows them says so. Predicted grades are refused outright — the framework hasn’t published the thresholds, so the system doesn’t guess them.
Audit the build, not just the brief.
Sixty-nine requirements traced back to the engagement that produced them, each given a verdict and its evidence. Eight defects found and closed, two of them serious, before the package was called complete.
Say what a copy cannot do, in the copy.
A hosted copy and a local copy behave differently — a browser can’t open a file:// path from a website, and shouldn’t. Rather than hide that, the portal detects which copy it is and states the difference on screen.
Outcome
The result is a working prototype an accreditation team can use to prepare a return — real definitions and real submitted values, a clear line around what the current year hasn’t proven yet, and an audit trail confirming the build does what it claims. Sixty-nine requirements were checked; eight defects were found and closed before the package shipped.
Takeaway
The discipline to keep real evidence, mid-year estimate and refused prediction visibly distinct — and to audit a build against its own requirements rather than call it finished on say-so.
Honest limits
No server: nothing persists past the browser tab except the sign-in and a chosen corpus root. No live monitoring — the external-awareness panel is a specification, and says so on screen. The NIRF and AISHE views use a working crosswalk, not a published mapping. This is a prototype for institutional review, not a system already live in production.
What would come next
- Institutional review of the seven role scopes and the metric crosswalks
- A server-backed identity and persistence layer
- A controlled pilot against the current accreditation cycle