Field dictionary
Agree what a field means, then define how it must be interpreted and checked.
Join both parts with the same Field IDF-01 to F-06
Practical checklist · Student data preparation
14-minute readStudent data import preparation: fields, formats and validation checks.
Print the linked field-dictionary and exception-log templates first, then complete them against the school’s agreed scope. Define every field, preserve stable identifiers, validate relationships, record decisions and reconcile a controlled trial before any production move.
Reviewed against official NDEAR, Ministry of Education, W3C and MeitY sources and with the Remonthub product team
Offline decision templates—not an upload screen or a public Schylva import schema. Use fictional planning entries; keep live student and guardian records out of this page and public enquiry forms.
The short answer
Define the meaning.
Prove the relationships.
Use the same field ID across the two blank dictionary tables and the same exception ID across the two blank log tables. Freeze the population and cut-off, preserve an untouched source extract, record school-owned meaning and mapping decisions, validate identifiers and relationships, then reconcile a versioned trial with named owners. These templates document decisions; they are not a public Schylva schema or self-service upload interface.
From a bounded source to school-owned acceptance.
Two records. Four linked sheets.
Keep the key. Complete both parts.
Each pair is one record split for readability. Match its IDs across A and B, then review the dictionary and exception decisions together before a controlled trial.
Exception log
Keep the problem and its impact connected to the authorised decision and retest.
Join both parts with the same Exception IDE-01 to E-04
Print and complete offline. The lines are writing spaces, not editable fields or saved approvals. Keep live records in the school’s approved protected workflow.
Print and use first
Complete one school-owned field dictionary and exception log.
Print or copy these blank linked tables, then complete them only after the school freezes scope and names its owners. Use Field ID to join the two dictionary tables and Exception ID to join the two log tables without forcing every decision into one unreadably wide sheet.
| Field ID | Source system, object and field | School meaning, domain owner and approver | Target, approved disposition and status |
|---|---|---|---|
| F-01 | System/object/field: __________________ | Meaning: __________ · Owner/approver: __________ | Target: ____ · Disposition: map / transform / hold / exclude · Status: ____ |
| F-02 | System/object/field: __________________ | Meaning: __________ · Owner/approver: __________ | Target: ____ · Disposition: map / transform / hold / exclude · Status: ____ |
| F-03 | System/object/field: __________________ | Meaning: __________ · Owner/approver: __________ | Target: ____ · Disposition: map / transform / hold / exclude · Status: ____ |
| F-04 | System/object/field: __________________ | Meaning: __________ · Owner/approver: __________ | Target: ____ · Disposition: map / transform / hold / exclude · Status: ____ |
| F-05 | System/object/field: __________________ | Meaning: __________ · Owner/approver: __________ | Target: ____ · Disposition: map / transform / hold / exclude · Status: ____ |
| F-06 | System/object/field: __________________ | Meaning: __________ · Owner/approver: __________ | Target: ____ · Disposition: map / transform / hold / exclude · Status: ____ |
Keep the same Field ID in both parts.
Continue to dictionary part B| Field ID | Type, format and allowed values | Required, blank and default rule | Key, relationship, transformation and validation rule |
|---|---|---|---|
| F-01 | ____________________________ | ____________________________ | ____________________________ |
| F-02 | ____________________________ | ____________________________ | ____________________________ |
| F-03 | ____________________________ | ____________________________ | ____________________________ |
| F-04 | ____________________________ | ____________________________ | ____________________________ |
| F-05 | ____________________________ | ____________________________ | ____________________________ |
| F-06 | ____________________________ | ____________________________ | ____________________________ |
Keep the same Field ID in both parts.
Return to dictionary part A| Exception ID | File/version and record key | Expected rule, supplied value and observed issue | Severity/impact, owner and due date |
|---|---|---|---|
| E-01 | File/version/key: __________________ | Rule: ____ · supplied value: ____ · issue: ____ | Severity/impact: ____ · Owner: ____ · Due: ____ |
| E-02 | File/version/key: __________________ | Rule: ____ · supplied value: ____ · issue: ____ | Severity/impact: ____ · Owner: ____ · Due: ____ |
| E-03 | File/version/key: __________________ | Rule: ____ · supplied value: ____ · issue: ____ | Severity/impact: ____ · Owner: ____ · Due: ____ |
| E-04 | File/version/key: __________________ | Rule: ____ · supplied value: ____ · issue: ____ | Severity/impact: ____ · Owner: ____ · Due: ____ |
Keep the same Exception ID in both parts.
Continue to exception log part B| Exception ID | Approved disposition and decision authority | Resolution version, evidence and retest result | Closure evidence, status and date |
|---|---|---|---|
| E-01 | Disposition/authority: __________________ | Version/result: ______________________ | Evidence/status/date: ________________ |
| E-02 | Disposition/authority: __________________ | Version/result: ______________________ | Evidence/status/date: ________________ |
| E-03 | Disposition/authority: __________________ | Version/result: ______________________ | Evidence/status/date: ________________ |
| E-04 | Disposition/authority: __________________ | Version/result: ______________________ | Evidence/status/date: ________________ |
Keep the same Exception ID in both parts.
Return to exception log part ABefore the file
Define the population, purpose and cut-off before preparing rows.
An import becomes difficult to control when “all student data” is the only scope statement. Name the exact population and operational purpose before anyone cleans, merges or transfers a file.
01 · Population
Which records belong?
Define academic session, campus, class range, active or inactive status and any excluded historical population.
02 · Domains
Which facts are needed?
Separate core student, guardian relationships, class placement, accounts and each optional history domain instead of treating them as one table.
03 · Time
When does the source stop changing?
Record the extraction time, working-copy version, final cut-off and how approved changes after the trial will reach the final load.
04 · Authority
Who can decide meaning?
Name the school owner for every domain, the implementation contact, the exception approver and the final acceptance owner.
| Decision | Record it precisely | Unsafe shortcut |
|---|---|---|
| Purpose | The supported launch workflow that requires the records | Moving fields because they exist in the old system |
| Population | Session, campus, status, class range and explicit exclusions | Every student ever created |
| Source of record | Named system or approved file and its responsible owner | Whichever spreadsheet appears newest |
| Cut-off | Extraction timestamp, freeze point and final-delta method | Editing the trial file until launch |
| Acceptance | Counts, field checks, relationship checks, samples and role workflows | The importer reported success |
| Retention | Authorised source, working-copy and exception-log treatment | Deleting the source after the first load |
- The academic session, campus, class range and student statuses are explicit.
- Every data domain has a named school owner and a stated launch purpose.
- An untouched source extract and a versioned working copy are distinct.
- The cut-off and final-delta approach are recorded before the trial.
- Excluded history is documented rather than silently omitted.
Meaning before mapping
Build a field dictionary that both the school and implementation team can read.
A familiar column name can hide a different business meaning. “Class,” “status” and “guardian” may each encode several concepts, so a mapping needs definitions and examples—not only source and target headers.
| Source field | Intended meaning | Format or values | Rule | Fictional example |
|---|---|---|---|---|
| student_code | School-controlled stable student identifier | Text; preserve leading zeros | Required and unique in the agreed population | STU-0007 |
| academic_session | Session governing the placement record | Approved session code | Must reference one configured session | SESSION-2026 |
| class_code | Reference to the configured class—not free-text display copy | Approved reference code | Must exist in class reference data | CLASS-06 |
| section_code | Reference to the section within the agreed class context | Approved reference code | Required only where section applies | SECTION-B |
| guardian_code | Stable identifier used to link a guardian relationship | Text | Must resolve to an approved guardian record | GUARD-002 |
| relationship_type | School-confirmed relationship label | Approved value list | Do not infer from name, phone or gender | Guardian |
| date_of_birth | Student date of birth where included and lawfully needed | YYYY-MM-DD | Validate date and agreed range; never use a real value in a demo | YYYY-MM-DD |
The official NDEAR open-standards document describes interoperability, portability, uniqueness, reference data and consistently understood education information. Those principles support explicit meanings and stable references, but they do not prove that a private school ERP or one import file is NDEAR-compliant.
Inventory every supplied column.
Record its source system, owner, current use, known blank meaning and whether it belongs in the agreed launch scope.
Write the business definition.
Explain what the field means at this school, which record it describes and which other field or reference gives it context.
Define type and allowed values.
Specify text, integer, decimal, Boolean, date, timestamp or reference; then name permitted codes, blank rules and normalisation rules.
Name the key or relationship.
Mark primary identifiers, duplicate rules and foreign references so the migration does not rely on visual order or names alone.
Record the approved disposition.
Map, transform, derive with an authorised rule, hold for decision or exclude with a stated reason. Never silently drop an ambiguous field.
Structure without distortion
Normalise the file without changing the school’s meaning.
CSV, spreadsheet and database extracts can all carry valid data, but each can introduce type, encoding and display problems. Confirm the exact transfer format and protect values that software tends to reinterpret.
| Control | Expected preparation | Example failure to detect |
|---|---|---|
| Headers | One approved header row with unique, mapped column names | Merged headings or repeated column labels |
| Rows | One agreed record type per row with no subtotal or note rows | A section title is read as a student |
| Encoding and delimiter | Confirmed encoding, delimiter, quote and line-break handling | Names or addresses become corrupted or split across rows |
| Identifiers | Stored as text when leading zeros or long digit strings matter | 000731 becomes 731 or a long value is rounded |
| Dates and time | One unambiguous agreed format and time-zone rule | 03/04/2026 changes between 3 April and 4 March |
| Blanks | Missing, not applicable, unknown and zero have defined meanings | A blank fee balance is converted to zero |
| Formulas and macros | Approved values are exported; hidden logic and external links are removed or documented | A formula recalculates differently on another machine |
| Multiple sheets | Each sheet or file has one stated object and relationship path | The wrong sheet is treated as the final population |
- Open the prepared file using the same interpretation expected by the migration process.
- Check multilingual characters, punctuation, embedded commas and line breaks.
- Compare stored cell values with what the spreadsheet visibly displays.
- Confirm leading zeros, long identifiers and date formats after export and reopen.
- Remove blank trailing rows, subtotal rows, comments and decorative merged cells.
- Record file name, byte size, version, row count and an integrity identifier before transfer.
People are not rows
Test stable identities and relationships before matching records.
Names, phone numbers and email addresses can be shared, changed, mistyped or absent. Relationships should resolve through approved identifiers and reference data—not a guess based on similar personal details.
| Check | Pass condition | Exception example |
|---|---|---|
| Student uniqueness | Every in-scope student ID occurs according to the approved uniqueness rule | STU-0007 appears twice with conflicting class placement |
| Guardian uniqueness | The agreed guardian identifier resolves without merging distinct people | Two guardians share a phone number but are different records |
| Guardian-to-student link | Every relationship references existing approved records on both sides | GUARD-002 references an excluded or unknown student ID |
| Academic placement | Session, class and section references exist and form a valid configured combination | SECTION-B exists, but not under CLASS-06 in the target session |
| Account relationship | Only the agreed person and role records receive account treatment | A historical or inactive record is unintentionally activated |
| Cross-file reference | Every foreign reference resolves to the exact versioned reference file | A class code was renamed in one file but not another |
Exact duplicate
Same key, same approved values
Confirm whether it is a repeated row, a valid repeated relationship or evidence that the uniqueness rule is wrong.
Key collision
Same key, conflicting facts
Stop that record path and obtain a school decision; do not select whichever row appears last.
Possible person match
Similar details, different keys
Treat it as an investigation candidate, not proof that the people are identical.
Orphan reference
Relationship points nowhere
Correct the reference, add an approved parent record, remove the out-of-scope link or hold it as an exception.
Four layers of evidence
Validate structure, values, relationships and school totals separately.
A file can be syntactically valid while its records are wrong. Run repeatable checks in layers and retain a machine-readable rejection or exception log for every failed rule.
| Layer | Representative checks | Evidence to retain |
|---|---|---|
| Structure | Expected headers, file type, encoding, row shape, no hidden totals or duplicate headers | File version, parser result and rejected row locations |
| Field values | Required values, type, date range, allowed codes, text length and blank semantics | Rule ID, record key, supplied value and disposition |
| Identity | Unique keys, collisions, possible duplicates and inactive-record rules | Duplicate group and authorised decision |
| Relationships | Guardian, class, section, session and other approved references resolve | Parent key, child key, expected reference and exception owner |
| Aggregates | Counts by campus, session, class, section and agreed status | Source total, prepared total, trial total and explained variance |
| Representative records | Typical, blank, multilingual, duplicate-risk and boundary cases | Redacted sample IDs, expected result and reviewer outcome |
| Record key | Rule | Observed issue | Owner | Disposition |
|---|---|---|---|---|
| STU-0007 | CLASS_SECTION_REFERENCE | SECTION-B is not configured beneath CLASS-06 for SESSION-2026 | Academic data owner | Open—confirm intended placement |
| STU-0014 | GUARDIAN_REFERENCE | GUARD-099 does not exist in the approved guardian file | Student-record owner | Open—supply or remove relationship |
| STU-0021 | IDENTIFIER_UNIQUENESS | Stable ID occurs with conflicting status values | Migration decision owner | Held from trial pending decision |
Controlled migration round
Transfer through the approved route, reconcile a trial and close exceptions visibly.
Once the prepared dataset passes preflight, the implementation team still needs a reproducible transfer, a controlled trial and written school acceptance. Do not use public forms, email by habit or a production launch as the first complete test.
Freeze the prepared dataset.
Record file names, versions, byte sizes, row counts, mapping version, validation result and an integrity identifier. Resolve or explicitly hold every material exception.
Use the approved transfer route.
Follow the school-specific implementation channel and authorised access process. Do not place live records in a demo request, quote form, chat, public link or unapproved personal account.
Run the agreed trial scope.
Use a representative, controlled dataset or the agreed full trial round. Capture importer results, rejected records, transformation logs and the exact target configuration version.
Reconcile independently.
Compare source, prepared and target counts by meaningful groups; check values and relationships; then inspect representative records and included role workflows.
Classify every variance.
Distinguish approved exclusions, source defects, mapping decisions, transformation defects, target-configuration defects and unresolved school decisions.
Approve, rerun or stop.
A named school owner signs the accepted evidence and exceptions. Material mismatches trigger correction and another controlled round—not a silent waiver for the launch date.
| Evidence | Pass question | Owner |
|---|---|---|
| Version control | Can the exact source, prepared files, mapping and transformation rules be reproduced? | Implementation lead |
| Population reconciliation | Do source, prepared and target totals agree by meaningful group, with every variance explained? | Student-record owner |
| Field verification | Do required values, codes, dates, blanks and identifiers retain their approved meaning? | Domain owner |
| Relationship verification | Do student, guardian, session, class and section links resolve correctly? | Student-record and academic owners |
| Role workflow | Can authorised users find and use the migrated context required by the included launch workflow? | Role-workflow owner |
| Exceptions | Does every remaining item have an authorised disposition, owner and impact statement? | Migration decision owner |
- The trial input can be identified byte-for-byte and reproduced.
- Rejected records and transformations have record-level evidence.
- Counts are reconciled by meaningful school groups, not total rows alone.
- Fictional or formally approved representative records cover edge cases.
- Included role workflows are checked after the data-level review.
- Every open variance has a named owner and an authorised launch disposition.
- The final delta, go/no-go owner and rollback trigger are written.
Handle less, promise precisely
Protect student information and keep Schylva’s current import scope explicit.
Preparation copies can multiply sensitive information quickly. Limit the fields, copies, people and channels involved, and treat product scope as a written implementation decision rather than an assumption from this checklist.
Current public Schylva scope
- Initial data migration is included in the standard launch service
- Authorised school administrators can manage supported core student, teaching staff, guardian, class and section records
- One guardian can be linked to one or more students where configured
- Staff training and ongoing product support are included
Confirm in the written school plan
- Exact records, source files, fields and historical range
- Accepted formats, transfer method and migration rounds
- Mapping, transformation and relationship decisions
- Validation, acceptance, timing, owners and final delta
- Retention, deletion, export and school-specific security terms
Do not infer or claim
- A public self-service CSV or spreadsheet import screen
- Bulk import, export or third-party integration outside the written implementation scope
- Automatic matching from names, phones or email addresses
- Unlimited migration of every historical record
- Universal propagation of every changed field across all views
- NDEAR, DPDP or other blanket compliance certification
The NDEAR formal report emphasises clear purpose, privacy, security, permissions and special care for children’s information. India’s Digital Personal Data Protection Act, 2023 and Digital Personal Data Protection Rules, 2025 require qualified, current review for the school’s circumstances. This checklist neither decides applicability nor supplies a legal basis for processing.
- Only fields needed for the agreed migration purpose are included.
- Working copies, access, transfer and deletion responsibilities are named.
- Examples, screenshots and defect tickets contain fictional or approved redacted context.
- Public demo and quote forms are excluded from live data handling.
- Source retention and secure deletion remain separate authorised decisions after acceptance.
Frequently asked questions
Clarify the decision and its boundaries.
Use these answers as a starting point, then verify the relevant source, rule and school process.
Should a school prepare student data in CSV or Excel?
Use the exact format agreed in the written implementation plan. Either can carry useful tabular data, but both need explicit rules for headers, encoding, identifiers, dates, blanks, formulas, multiple sheets and relationships. Do not assume that a generic CSV or spreadsheet is a Schylva import template.
Which fields are required for a student data import?
There is no universal public field list. Required fields depend on the agreed launch workflow, school structure and written migration scope. Build a dictionary covering each field’s meaning, type, required or blank rule, allowed values, stable identifier, relationship, owner and disposition before preparing the final file.
How can a school preserve leading zeros and dates?
Treat identifiers as text where formatting is meaningful, use one unambiguous agreed date format such as YYYY-MM-DD, inspect stored values rather than display formatting, and reopen the exported file using the same interpretation expected by the migration process. Test fictional boundary examples before using approved live data.
Can duplicate students be matched by name and phone number?
Not safely as an automatic rule. Names and phone numbers can be shared, changed or mistyped. Use approved stable identifiers and supporting evidence, route uncertain candidates to a named school owner and record the authorised merge, link, replacement or exclusion decision.
When is a prepared import file ready for trial migration?
It is ready when scope and cut-off are frozen; the source, working file, dictionary and mapping are versioned; structure, values, identities, relationships and aggregates pass; material exceptions have authorised dispositions; and the approved transfer route, trial plan and reviewers are named.
Does a successful upload prove that the migration is correct?
No. It proves only that the technical process accepted some input. School acceptance also requires population reconciliation, value and relationship checks, representative records, included role workflows and a recorded disposition for every material variance.
Does Schylva offer a self-service bulk student import tool?
Schylva does not currently make that public claim. Initial data migration is included in the standard launch service, while the exact records, formats, method, rounds, validation and timing are confirmed in the school’s written implementation plan. Bulk import, export or third-party integration outside that written scope is not claimed.
Can live student data be sent through the demo form?
No. Use fictional or redacted context for a demonstration. Do not submit student, guardian, credential, payment or confidential school records through a public demo or quote form. Use only the approved implementation route for agreed live-data handling.
Primary sources and further reading
Read the official material behind the context.
Sources were reviewed when this checklist was updated on 2 September 2026. Always verify the current official version before relying on a rule or requirement.
Ministry of Education — NDEAR
Open Standards and Specifications for NDEAROfficial standards context for interoperable and portable education data, uniqueness, reference information, privacy, security and access control. It does not certify Schylva or prescribe this checklist as an import format.
Ministry of Education — NDEAR
National Digital Education Architecture — Formal Complete ReportArchitecture context for purpose, systems of record, permissions, interoperability, portability and protection of children’s information.
World Wide Web Consortium
Model for Tabular Data and Metadata on the WebTechnical model for interpreting tabular files and associated metadata. It is background context, not a Schylva-specific requirement.
World Wide Web Consortium
Metadata Vocabulary for Tabular DataTechnical vocabulary for describing columns, datatypes, constraints and keys around tabular data. This checklist converts the general principle into a readable school field dictionary.
Ministry of Education
UDISE+ Report 2024–25 — Existing StructureOfficial school-data report describing school-level collection, built-in validation checks and later verification. Verify current UDISE+ instructions separately; this is not a Schylva field list.
Ministry of Electronics and Information Technology
Digital Personal Data Protection Act, 2023Primary statutory source for qualified review. This checklist does not decide applicability or provide legal advice.
Ministry of Electronics and Information Technology
Digital Personal Data Protection Rules, 2025Official Gazette notification with phased commencement. Verify later notifications and obtain qualified advice where required.
Prepare one safe sample
Bring a fictional field dictionary and three difficult relationship cases.
A focused implementation discussion can verify the intended student, guardian, session, class and section meanings, identify the checks the school must own, and record the exact migration details that still need written confirmation—without placing live records in a public form.