Forward-Deployed Engineering · Education · Admissions operations
Case study: admissions documents, from upload to a verified pack an officer can decide on
Illustrative engagement — not a client record. The company, people, volumes and results below are a representative composite, written to show how a forward-deployed engagement runs end to end. The workflow, the architecture, the controls and the method are real and technically valid.
Offering usedProduction SprintOne workflow from prototype to production in six weeks.
Illustrative results, first 90 days after cut-over, in-scope applications only:
1.5 days
Median time from submission to "documents verified"
Before 9 days
78%
Applications reaching an officer complete at first touch
Before 31%
56%
Mark sheets verified from an official digital source
Before 0%
0, by design
Applicants rejected or ranked by the system
Before not applicable
Explainer09 sections
The whole story in about a minute
Nine short scenes, from the admissions season to the results. Press play, or pick a scene.
sections01 / 09
95,000 applications, every document checked by eye.
Each application carried four to nine documents, from more than thirty boards. Forty seasonal staff worked the queue, and a file took a median of nine days to be verified.
PeriodBefore
median from submission to a verified status9 days
- About 95,000 applications a cycle
- Four to nine documents each
- 40 seasonal verification staff
Enclosure01 / 09
Documents waiting
At a glance
- Client
- A private multi-discipline university with a large undergraduate intake: around 95,000 applications a cycle for roughly 9,500 seats, applicants from more than thirty school boards
- Workflow
- Application document processing: read transcripts, mark sheets, entrance scores, certificates and identity documents; check completeness; convert marks using published rules; check published eligibility criteria; verify against official digital document sources where the university is authorised; flag inconsistencies; answer applicant status questions
- Engagement
- Production Sprint (six weeks), with Handover & Enablement as its last two weeks
- Team
- One named senior forward-deployed engineer, full time. Client side: the Deputy Registrar, Admissions (owner), the admissions systems manager, two senior admissions officers, a platform engineer, the data protection officer, a security reviewer
- Where it runs
- The university's own cloud account and region. No data retained outside it
- Handover
- Runbook executed by the university's platform engineer before the exit gate on day 42; our access revoked the same day
| Measure | Before | After |
|---|---|---|
| Median time from submission to "documents verified" | 9 days | 1.5 days |
| Applications reaching an officer complete at first touch | 31% | 78% |
| Mark sheets verified from an official digital source | 0% | 56% |
| Applicants rejected or ranked by the system | not applicable | 0, by design |
| Status questions answered without a staff member | 0% | 64% |
FDE / 01Case study
01 / 12
In shortAbout 95,000 applications a cycle, mark sheets from more than thirty boards, and every document checked by eye.
Admissions opened in January and closed in June. In those months the university received around 95,000 undergraduate applications, each carrying between four and nine documents: class ten and class twelve mark sheets, passing certificates, an entrance examination score card, a category or domicile certificate where claimed, a photograph, an identity document, and in some programmes a portfolio or a sports certificate.
Documents came from more than thirty boards, and a national board's mark sheet looks nothing like a state board's. One reports subject marks out of 100, another out of 80 plus a 20-mark internal component, a third a nine-point grade with a published conversion, a fourth both. Some mark sheets are issued in a regional language with an English panel. Older ones are photocopies of photocopies.
Forty seasonal verification staff worked through the queue. The cost showed up in three places:
Time. An application took a median of nine days from submission to a verified status, and longer in the two weeks after each board published results. Applicants with offers elsewhere did not wait.
Rework. Fewer than a third of applications reached an officer complete. The rest bounced: a missing certificate, a mark sheet that did not open, a name spelled differently on two documents.
Trust. Every document was checked by eye. Forged mark sheets and mark sheets from unrecognised boards do circulate, and a manual check at volume is exactly where they get through.
FDE / 02Case study
02 / 12
In shortA vendor pilot read the easy documents and tried to rank applicants, so the committee said no.
The university had run a document-reading pilot with a vendor two cycles earlier, on a sample of one board's mark sheets.
It was tested on the easy half. The sample was one board, printed, recent. The queue is thirty boards, a third of them scanned badly.
It proposed to decide. The demonstration ended with an eligibility verdict and a suggested rank order. The admissions committee, correctly, would not accept a system that ranks applicants, and the conversation stopped there rather than moving to what the system could safely do.
It could not show its working. A score appeared with no indication of which line of which document it came from, so an officer could not check it faster than reading the document herself.
It had no answer on personal data. A large share of applicants are seventeen, and therefore children under India's data protection law. The pilot had no position on consent, retention or where the documents would be processed.
What was missing was not document reading. It was scope discipline, evidence, a lawful design and an owner inside the registrar's office.
FDE / 03Case study
03 / 12
In shortA week writing a one-page scope, starting with what the system must never do.
The university had already chosen the workflow, so the engagement began with the Production Sprint rather than a separate scoping sprint. Week zero was spent writing the scope with the Deputy Registrar and two senior admissions officers, and testing which access was real.
What was found:
FIG. 3.1- The admissions system exposed an approved API for reading applications and writing document status, checklist items and notes. Write-back could use the same path an officer uses.
- The university was already an issuer of its own degrees to the national digital document platform. It was not onboarded as a requester, which is a different agreement and a different approval. Everyone had assumed otherwise.
- Officers used at least three different conversion habits for one board's grade scale. Only one matched the board's published table.
- The prospectus stated eligibility precisely: minimum aggregate, subject combinations, and a published conversion for grade-based boards. It was the only rulebook, and it was already written.
The one-page scope, signed by the Deputy Registrar:
- WorkflowUndergraduate applications: read and classify documents, check completeness, convert marks using published rules only, check published eligibility criteria, verify against the national digital document platform with applicant consent, flag inconsistencies, answer status questions
- Out of scopePostgraduate admissions, international transcripts, scholarship and fee-waiver documents, hostel allocation, any ranking or shortlisting
- MetricShare of applications reaching an officer complete at first touch, with critical-field accuracy at or above 99.5% on the golden set and zero autonomous adverse outcomes
- OwnerDeputy Registrar, Admissions
- GuardrailsThe system never rejects, ranks or shortlists an applicant. It reports "meets the published criterion", "does not appear to meet — officer review" or "cannot determine". Every adverse-looking outcome goes to an admissions officer. Every applicant may ask a person to look again
- Exit gateOne week of shadow-run parity, one week live with rollback armed, runbook executed by the university's platform engineer, dry run passed before day 42
The guardrail row was written first and the rest of the page after it.
Timeline09 terms
The engagement, stage by stage
Nine stages on one clock, from the season before to ninety days after cut-over. Press play, or pick a stage.
Calendar09 / 09
Entry+90 days
Verified faster, and no one ranked by the system.
1.5 daysmedian from submission to verified, down from nine
Illustrative, first 90 days: submission to verified fell from nine days to 1.5, complete at first touch rose from 31% to 78%, and no applicant was rejected or ranked by the system.
- Complete at first touch 31% → 78%
- 56% of mark sheets verified at source
- 64% of status questions need no staff
FDE / 04Case study
04 / 12
In shortA six-week sprint that took seven weeks and a day, because the clock paused for an access agreement.
paused for five working days
W0Scope
What happened
Scope page signed; access requested for the admissions system, the document store and the national platform's requester onboarding
What existed at the end
The signed scope and an access register
What happened
Scope page signed; access requested for the admissions system, the document store and the national platform's requester onboarding
What existed at the end
The signed scope and an access register
What happened
Repository created in the university's source control; engineer in the admissions operations standup. The requester onboarding had not started; the registrar and counsel had to sign a terms-of-service agreement, and the sprint clock paused for five working days, as the scope provides
What existed at the end
First pull request merged on day seven: document intake, classification and the checklist writing back to the admissions system
What happened
Reading and conversion running behind a feature flag on real applications from the previous cycle. Golden set agreed with admissions officers
What existed at the end
A prototype and a golden set of 2,000 historical applications with officer-approved answers
What happened
Eligibility rules from the prospectus, inconsistency checks, the officer review screen, the status assistant, audit log, dashboards, the fairness report. Requester integration completed and consented fetches working. Shadow run began at the end of week four
What existed at the end
A system producing a verified pack for every application in parallel with the team, deciding nothing
What happened
Live for one programme group, then four, then all in scope, each step gated on the shadow comparison. The runbook was written this week, not the last
What existed at the end
Real applications processed, rollback one switch away
What happened
Handover & Enablement closed the sprint: the platform engineer performed a release, a rollback and a rules change without us at the keyboard on day 39
What existed at the end
Signed runbook, decision record, revoked access at the exit gate on day 42
paused for five working days
Calendar time was seven weeks and one day. The extra week was the paused clock in week one, recorded on the day it started and the day it ended.
FDE / 05Case study
05 / 12
In shortA system that reads, converts and checks by published rules, and leaves every decision to an officer.
Try an application05 / 08
Pick an application. Watch where it goes.
The same checks run on every application. What the documents show decides whether it becomes a verified pack or goes straight to an officer.
“Class twelve mark sheet, pulled from the digital platform with consent”
Application log08 / 08
- 01IntakeThe board's own issued record; marked verified at source
- 02ClassifyTyped as a class twelve mark sheet
- 03Read fieldsBoard, roll number and subject marks read, each with its place on the page
- 04ConvertMarks converted by the board's published table
- 05CompletenessNothing missing against the prospectus checklist
- 06EligibilityMeets the published criterion, with the clause it was checked against
- 07ConsistencyNames, date of birth and totals agree
- 08Verified packVerified pack in the officer queue
Intake. Documents arrive from the applicant portal and, where the applicant consents, are pulled from the national digital document platform. A consented pull returns the board's own issued record, which needs no attestation and cannot be edited by the applicant. A document fetched this way is marked as verified at source; a document uploaded by the applicant is marked as self-supplied, and the difference is visible to the officer.
Classify. Each file is typed: class ten mark sheet, class twelve mark sheet, passing certificate, entrance score card, identity document, category certificate, photograph, other. Files uploaded in the wrong slot are re-typed and the checklist corrected, which alone removed a large share of bounces.
Read fields. A layout-aware document model reads the page, keeping the subject table intact. A language model, reached through a private endpoint in the university's region with no data retention, fills a strict schema: board, roll number, candidate name, parent names, date of birth, year of passing, subject rows with marks obtained and maximum marks, grades where used, and the result line. Every field carries the region of the page it came from, so the officer sees the evidence beside the value.
Convert. This is the part that needed the most restraint. Marks are converted only by rules the university or the board has published: the board's own grade-to-marks table, the prospectus's method for computing the aggregate of the best subjects, and the treatment of internal components as the prospectus states. There is no model judgement and no cross-board statistical normalisation. Where a board's scheme has no published conversion, the system returns "cannot determine" and routes the application to an officer with the mark sheet open. Comparing the standards of different boards is an admissions policy question owned by the admissions committee, and the scope said so.
Check completeness. Deterministic rules against the prospectus checklist for the programme applied for, including subject combinations and certificate requirements for any claimed category. The applicant sees exactly what is missing, in the same words the prospectus uses.
Check eligibility. A rules engine, not a model, applies the published criteria and returns one of three results:
Meets the published criterion, with the numbers and the clause of the prospectus it was checked against;
Does not appear to meet — officer review, which is never shown to the applicant as a decision and never closes an application;
Cannot determine, when a value is missing, unreadable or has no published conversion.
The second and third both land in an officer's queue. The system has no fourth outcome, and no ranking anywhere.
Flag inconsistencies. Name, parent name and date of birth compared across documents; marks summed against the stated total; year of passing compared with the class ten record; the board checked against the university's list of recognised boards; images checked for the signs of tampering that are checkable, such as inconsistent fonts within a table or a digitally edited region. A flag is a reason to look, never a finding of fraud. The officer decides, and a flagged applicant is told what document is in question and invited to supply the issued record through the digital platform.
Status assistant. Applicants ask where their application stands. The assistant answers from the application record only: what has been received, what is missing, what stage the file is at, and what happens next. It is forbidden to predict an outcome, to comment on chances, or to answer anything outside the record; those become a call-back request. Every answer is logged and sampled weekly by admissions.
Where the decisions sit. A model reads and extracts with evidence. Rules convert, check and flag. An admissions officer decides every edge case, every inconsistency, and every eligibility question the rules could not settle. Offers are made by officers under the admissions committee's criteria. The system cannot reject, rank, shortlist or close an application.
Audit and monitoring. Every document read, conversion applied, rule result, flag, officer decision and assistant answer goes to the university's log store with the model version. Dashboards show queue depth, first-touch completeness, flags by type, and the weekly audit accuracy. A fairness report runs weekly: read-failure rates, flag rates and "cannot determine" rates broken down by board, by document source and by language of the mark sheet, so that a group of applicants cannot quietly be made to wait longer than another.
System map20 objects
How the pieces connect
Every document, rule, person and system, lit one scene at a time. Press play, or pick an event.
Graph3 / 20 objects
Person04
Deputy RegistrarownerNot in this scene
ApplicantIn this scene
Admissions officerdecidesNot in this scene
Platform engineeruniversityNot in this scene
Document04
One-page scopesignedNot in this scene
RunbooksignedNot in this scene
Verified packNot in this scene
Prospectusthe only rulebookNot in this scene
Dataset01
Golden set2,000 applicationsNot in this scene
Check01
CI gate99.5%Not in this scene
Report01
Fairness reportweeklyNot in this scene
Service03
IntakeNot in this scene
Document readerevidence per fieldNot in this scene
Rules enginepublished rules onlyNot in this scene
System02
Admissions systemapproved APIIn this scene
Digital platformwith consentNot in this scene
Control01
Rollback flagNot in this scene
Team01
Verification staff40 seasonalIn this scene
Project01
Vendor pilotone boardNot in this scene
Agent01
Status assistantrecord onlyNot in this scene
Object01 / 09
95,000 applications, every document checked by eye.
9 daysmedian from submission to a verified status
Each application carried four to nine documents, from more than thirty boards. Forty seasonal staff worked the queue, and a file took a median of nine days to be verified.
- About 95,000 applications a cycle
- Four to nine documents each
- 40 seasonal verification staff
Linked objects
Applicant → Admissions system
Admissions system → Verification staff
FDE / 06Case study
06 / 12
In shortA test of 2,000 past applications that every build must pass, scored board by board.
The golden set was built with two senior admissions officers over the first two weeks, from the previous cycle's applications.
2,000 historical applications, sampled to over-represent the difficult: every board with more than a hundred applicants, regional-language mark sheets, poor scans, mark sheets with supplementary attempts, name changes, and applications that had been bounced twice.
Answers taken from what officers finally recorded, not from what the document appeared to say.
Field-level scoring, with critical fields — roll number, board, year, subject marks, maximum marks, aggregate, date of birth — carrying a 99.5% threshold.
Outcome scoring on the three-way eligibility result, with one rule weighted above all others: a "meets the published criterion" that officers had recorded as not meeting is the worst possible error, and any occurrence fails the build.
A red-team slice: an edited mark sheet, a mark sheet from an unrecognised board, a subject table whose marks do not sum, two applicants with the same name and different roll numbers, and prompts inside an applicant's uploaded file attempting to instruct the reader.
A fairness slice, scored by board and by language, so that accuracy could not be reported as an average that hid one board.
- IF a "meets the published criterion" that officers had recorded as not meetingBLOCKS
fails the build
The suite runs in the university's CI. In week four it stopped a release: a change that improved reading of one state board's layout began swapping "marks obtained" and "maximum marks" on another board whose table puts the maximum first. The aggregate looked plausible in both cases, which is precisely why a person would not have caught it quickly. The harness did, and the build failed before anything reached an officer.
FDE / 07Case study
07 / 12
In shortEverything stays in the university's cloud, with parental consent for under-eighteens and no ranking anywhere.
Perimeter. Everything runs in the university's cloud account and region. Egress is limited to the private model endpoint, which retains nothing, and to the national digital document platform, which is called only with the applicant's consent and only for the document types the university is authorised to request.
Children's data. A large share of applicants are under eighteen, and therefore children under India's data protection law. The university's data protection officer and counsel took the conservative reading: the exemption available to educational institutions is narrow, so the university collects verifiable parental consent for under-eighteen applicants at registration, records it, and processes on that basis. No behavioural tracking and no advertising to applicants of any age happens anywhere in the system. The substantive obligations take effect in 2027; the design was built to them now rather than retro-fitted later.
Retention. Documents and extracted fields follow the university's published retention schedule, with the records of applicants who are not admitted deleted after the cycle's dispute window closes. Deletion is a runbook step, with a report.
Identity. The service account can read applications and write document status, checklist items and notes. It cannot change a mark, an eligibility decision, an offer or an application's state. Our engineer's access went through the university's identity provider and was revoked at the gate.
Can
- read applications
- write document status, checklist items and notes
Cannot
- change a mark
- an eligibility decision
- an offer
- an application's state
Autonomy is bounded. The system never rejects, ranks or shortlists. Every adverse-looking outcome is an officer's to decide. Every applicant can ask for a human review of a flag or a "does not appear to meet", and that route is printed on the portal, not buried.
Untrusted input. Applicant uploads are treated as hostile: text inside a document is data, never instruction, and the red-team slice tests it every build.
Review. The security team reviewed the design in week two and the deployment in week five. The data protection officer reviewed the consent flow, the retention schedule and the fairness report. Findings and how each was closed are in the decision record.
FDE / 08Case study
08 / 12
In shortA week side by side with the team, then live group by group, with one flag to switch it off.
The shadow run was the gate. For a week the system produced a verified pack for every in-scope application while the verification team worked as before, and the two were compared field by field and outcome by outcome. Disagreements went into three piles: the system was wrong, the officer was wrong, and the prospectus was ambiguous. The third pile — four clauses, mostly about subject combinations — went to the Deputy Registrar and was settled in writing before go-live.
For a week
the system was wrong
the officer was wrong
the prospectus was ambiguous
went to the Deputy Registrar
Rollout went by programme group, not by date: one group, then four, then all in scope. Each step needed a clean day of audit samples and a fairness report with no board's "cannot determine" rate above the agreed level. Rollback was one flag that returned every application to the manual queue; it was tested in week five and used once, for an afternoon, when a board published results in a new layout and the "cannot determine" rate on that board rose sharply. Those applications went to officers, the layout was added, and the flag was turned back on the next morning.
01one group
02then four
03then all in scope
EACH STEP · a clean day of audit samples and a fairness report with no board's "cannot determine" rate above the agreed level
a board published results in a new layout
the "cannot determine" rate on that board rose sharply
- for an afternoon
used once
the flag was turned back on the next morning
CONTROL ·one flag that returned every application to the manual queue
FDE / 09Case study
09 / 12
In shortThe university's platform engineer proved they could run it before we left.
Handover & Enablement was the last two weeks of the sprint, not an addition to it.
In the dry run on day 39, the platform engineer added a board layout, scored it against the golden set and the fairness slice, released it, changed a published conversion, and rolled the release back, with our engineer in the room and off the keyboard. The runbook was signed after that, and the exit gate closed on day 42.
Key numbers09
The story in nine numbers
One number for each scene, from nine days to verified down to 1.5. Press play, or pick a number.
Scoreboard01 / 09
9 days
median from submission to a verified status
Lines01 / 09
NoteAdmissions season
95,000 applications, every document checked by eye.
Each application carried four to nine documents, from more than thirty boards. Forty seasonal staff worked the queue, and a file took a median of nine days to be verified.
- About 95,000 applications a cycle
- Four to nine documents each
- 40 seasonal verification staff
FDE / 10Case study
10 / 12
In shortFaster verification, more complete files, and no applicant rejected or ranked by the system.
Figures are illustrative, measured on in-scope undergraduate applications over the first 90 days after cut-over.
Median time from submission to "documents verified" fell from nine days to 1.5. The largest single gain was files no longer bouncing for a document that had been uploaded in the wrong slot.
78% of applications reached an officer complete at first touch, up from 31%.
BEFORE31%AFTER78%56% of class twelve mark sheets were verified from the official digital source, with the applicant's consent. The rest remain self-supplied, because coverage varies by board and by year of passing, and because consent is the applicant's to give.
BEFORE0%AFTER56%99.6% critical-field accuracy in the weekly audit sample, against the 99.5% threshold, with no board falling below 99% in the fairness report.
AFTER99.6%64% of status questions were answered without a staff member, and the weekly sample found no answer that predicted an outcome.
BEFORE0%AFTER64%No applicant was rejected, ranked or shortlisted by the system, because the design does not allow it. Every offer was made by an admissions officer.
The verification team was not reduced. Seasonal headcount stayed for the peak, and the team spent it on flagged cases and on applicants who needed a phone call.
What did not improve, and was never promised:
FIG. 10.2International transcripts are still evaluated by hand. They were out of scope.
Pre-digital mark sheets, chiefly from applicants who passed several years earlier, are read poorly and go to officers.
The peak on results day still overwhelmed the call centre. Faster verification did not reduce the number of people who want to speak to someone the day their board publishes.
Comparability between boards is exactly where it was. That is an admissions policy question, and the engagement deliberately did not touch it.
FDE / 11Case study
11 / 12
In shortSix rules for anyone building a system that sits beside admissions decisions.
- Write the guardrail before the scope.
"The system never rejects or ranks" made every later argument shorter, including the ones with us.
- Only convert by a published rule.
If a board has not published a conversion, the honest output is "cannot determine", not a clever guess.
- Score by board, not on average.
An average accuracy hides the one board whose applicants are being made to wait.
- Use the issued record where you are authorised to.
A consented pull from the source beats any amount of reading, and it is the applicant's choice to make.
- Check your access agreements before week one.
Being an issuer is not being a requester; that assumption cost five days.
- Publish the human route.
A flag an applicant cannot contest is not a flag; it is a decision in disguise.
FDE / 12Case study
12 / 12
In shortThe university ran the next cycle on its own and came back for postgraduate admissions.
The university ran the system through the following cycle with no engagement in place. Their admissions systems manager added eleven board layouts and two changed conversions between cycles, each scored against the golden set before release. They came back for a scoped sprint on postgraduate admissions, where international transcripts and credential evaluation are the hard part, and asked us to look at scholarship document processing after that.