Grading should be configuration, not a code fork

The symptom you have probably seen

A state-board school buys an ERP and gets a report card with a letter-grade column it does not use, a pass mark it does not apply, and a term structure that is not its own. The vendor says a custom template is possible. Six weeks later a designer sends a mock-up, and the marks still come out on the wrong scale — because the scale was never the template's decision.

That whole sequence is a symptom of one architectural choice: the board was written into the code rather than stored as data. Once a product contains a branch that reads "if the board is CBSE, do this", every additional board is a code change, every state variant is a backlog item, and no school can ever fix its own grading without the vendor.

The principle: the board is a school's configuration

The alternative is to make the board a configuration record that resolves in tiers. The school's own override wins if it exists; otherwise a curated library of board definitions applies; otherwise a built-in default. A school that has never touched the settings still gets a sensible card, and a school with an unusual state variant edits its own copy without waiting for anybody.

This is not purism. It decides whether grading is a support ticket or a Tuesday afternoon.

What should be configuration, concretely

If a vendor tells you the board is configurable, ask which of these a school can actually change without a release.

• Grading bands and the pass mark. The band table itself — label, range, and what counts as a pass — not just the colours on screen.
• The scale type. Grade points, a numeric scale, or marks and percentage. This matters more than it sounds: a marks-only board's card should drop the letter-grade column entirely rather than print an empty one.
• Term structure and the academic-year start month. An April start and a June start are both normal in India, and both change how a year's terms line up.
• Attendance thresholds. What counts as short attendance on the card, and at what percentage a warning appears.
• NEP holistic domains and their rating vocabulary. If the product supports a holistic progress card, the domains and the words used to rate them belong to the school and its board, not to the software.
• Result classification. Division bands, whether a grace rule applies and with what limits, and how many subject failures put a student into a compartment or re-examination rather than a straight fail.
• Card layout. Which sections print, and in what order. A school that does not use co-scholastic ratings should be able to remove that block rather than print an empty one.

One decision should propagate

The real test of a configuration-driven design is what happens after you change the board. Selecting a board should re-derive the grading and exam configuration that the rest of the system reads — the same band table that colours a mark in the gradebook should be the one that prints on the card and the one the result classification uses. If you have to set the pass mark in three places, you do not have configuration; you have three unrelated settings that happen to be near each other.

The corollary is that changing a board mid-year is a governed act, not a dropdown you nudge. Expect a confirmation, and expect already-generated cards to keep the configuration they were generated under rather than silently re-rendering under new rules.

Configuration without governance is worse than a code fork

Making grading editable raises the stakes, so the controls around who may enter, change and release marks matter as much as the flexibility itself. Four are worth insisting on.

1. Marks entry is scoped to the teacher's own sections. A subject teacher should not be able to open a neighbouring section's marks sheet, and this should be enforced on reading as well as on saving.
2. A second examiner, where used, must be a different person. If the product offers moderation, the person who verifies must not be the person who entered — and editing a paper after submission should invalidate the earlier verification rather than leave a stale approval attached to changed marks.
3. Publication is deliberate and reversible in the right direction. Releasing results to families should be an explicit action, and it should be possible to withhold one student's card inside an otherwise published term without unpublishing the whole class.
4. Approval separates from generation. Whoever generates a batch of cards should not be the only signature on them.

One boundary is worth stating about AI on report cards. A model can draft a remark, or propose a holistic domain rating, from evidence the school has already recorded — genuinely useful when a class teacher has forty cards to write. It must not save, approve or publish the final assessment. Insist on seeing the confirmation step.

How this works in Vidyapeeth360

Board configuration is a founding architectural invariant here: the board is tenant configuration and never a code branch. A three-tier resolver reads the school's own override, then a platform-curated board library, then a built-in default — so an untouched school gets sensible grading and a school with a local variant edits its own copy.

The editable surface is the Report Card Studio: grading bands, pass mark, scale type, holistic domains and ratings, term schema, attendance thresholds and the academic-year start month, plus division bands, a grace rule and the compartment threshold as ordinary data. Selecting a board re-derives the report-card and exam configuration the rest of the product reads. Printed body sections can be reordered and individually switched off, and the change reaches the generated PDF rather than stopping at the preview. Designs save as named, immutable versions, so a school can roll back to last year's card without rebuilding it.

On the governance side, marks entry is limited to the sections a teacher is actually assigned; an optional second-examiner step requires a different person and is invalidated if the marks are edited afterwards; scheduling a paper that overlaps another for the same class-section is blocked unless an authorised person records an override; and a report card can be approved, published or withheld individually, with the approver distinct from whoever generated it. AI drafts remarks and holistic ratings from recorded evidence and stops short of saving or publishing.

Two boundaries worth stating plainly: we do not claim a complete PARAKH template pack, and invigilator rostering, room allocation and seating plans are not part of the exams module today. The related surfaces are digital gradebook, result publishing and exam scheduling.

The one-line vendor test

Bring last year's report card to the demo and ask for it back. Not a template that resembles it — your class, your subjects, your scale, your section order. Whether the vendor can do that in the session, by changing settings rather than promising a customisation, tells you more about the next five years than any feature list will.