State reporting, validated before submission
The submission is due Friday. The file will either be accepted or it will come back as a list of error codes with record numbers, and finding the actual problem means opening each one by hand.
For a district data manager in a submission window.
State reporting, validated before submission
Illustrative sample. Not a client record.
| Student | Item | Status |
|---|---|---|
| S-104882 | Enrollment complete | Queued |
| S-104883 | Missing demographic Race/ethnicity is blank. The state rejects the whole file for this, not just the record. | Queued |
| S-104884 | Enrollment complete | Queued |
| S-104885 | Date conflict Exit date precedes entry date by 3 days. Almost always a transfer keyed in the wrong order. | Queued |
| S-104886 | Service code Special education service code retired in the current specification. Maps to the replacement code. | Queued |
| S-104887 | Enrollment complete | Queued |
Three records would have failed at the state and taken the whole submission with them. Each is named with the field at fault and what it usually means, so the person fixing it does not have to work out what the error code meant.
Today this is a rejected file, an error report of numeric codes, and a day spent reconciling it against the source system.
This is a demonstration, not a product. Every record above is invented. The point is not the table — it is that the exception is named, with the field at fault and what it usually means, rather than returned as a code somebody has to decode.
What we would build for you runs on your data, in your environment, and looks like your process rather than this one. More on this category: Education systems.
The other three
- One permit queue across three departments A permit technician and the departments they chase
- One number, from three systems that disagree A finance director assembling a board packet
- Public records requests, against the clock A city secretary or records officer