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: ____ |
| 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 | ____________________________ | ____________________________ | ____________________________ |
| 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: ____ |
| 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: ________________ |
Template boundary
This is a school-owned decision record—not a public Schylva import schema.
Do not infer accepted Schylva fields, formats, targets or a self-service upload capability from these blank tables. Confirm the exact migration scope and transfer method in the written implementation plan, use fictional entries for planning, and move authorised live records only through the approved protected route.
Before 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 |
Preserve evidence
Keep the original extract untouched and version every working copy.
Hash or otherwise identify the approved source extract, store it through the agreed protected route and make transformations only in a versioned working copy. Record who produced each version, when it was produced and which rules changed. That evidence makes a mismatch explainable and a rerun reproducible.
- 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.
Mapping boundary
A source field and a target field with similar labels are not automatically equivalent.
Ask whether the population, time period, granularity, allowed values, blank semantics and owner match. If meaning remains ambiguous, keep the item in an exception register for an authorised school decision instead of inventing a conversion rule.
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 |
Technical context
A CSV file does not carry all of its rules by itself.
The W3C’s tabular data model and metadata vocabulary illustrate how column names, datatypes, constraints, primary keys and foreign keys can be described outside raw cell values. Schylva does not require those W3C specifications; the practical lesson is to ship a readable dictionary and validation rules with the agreed data file.
- 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 |
No guessed matching
Do not merge two people from name, phone or email similarity alone.
Route uncertain duplicates to an authorised school owner with the relevant evidence. Keep the candidate records distinct until the owner approves a merge, replacement, link or exclusion. Record both the decision and the rule used so the final run behaves the same way.
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 |
Reporting context
Validation should be designed, not inferred from one total.
The Ministry of Education’s UDISE+ 2024–25 report describes school-level data collection with built-in validation checks and later verification. That is useful context for layered data-quality controls; it is not a Schylva field specification, a migration template or a substitute for current UDISE+ instructions.
Acceptance boundary
“File accepted” is not the same as “student data accepted.”
A technical parser can accept every row while identities, relationships, status meanings or totals remain wrong. Keep technical load evidence and school-domain acceptance as two separate gates.
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
Personal-data boundary
Use fictional or redacted records for planning and demonstrations.
Do not place student names, dates of birth, family contacts, identifiers, disability or health context, credentials, OTPs, payment details or confidential school information in a public form, shared screenshot or this checklist. Use the approved implementation route only after purpose, fields, access and handling are agreed.
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 NDEAR Official 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 Report Architecture 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 Web Technical 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 Data Technical 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 Structure Official 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, 2023 Primary 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, 2025 Official Gazette notification with phased commencement. Verify later notifications and obtain qualified advice where required.