Process for Error Resolution
Aug 17, 2026
Correct only after the cause is known
Use this page after you can explain what happened, which date/history is being corrected, and which source owns the error.
You are here: Correct.
What Needs to Be Corrected?
| SIRAS Current is wrongCorrect what is true now, then check whether older archives also need separate repair. | A historical SIRAS archive is wrongCorrect or replace the dated transaction without changing accurate Current data. |
| SIS/enrollment history is wrongCoordinate the source enrollment correction instead of distorting SIRAS dates. | CALPADS contains a blocking or incorrect transactionResolve the posted state history before resending dependent SIRAS data. |
| I have a SIRAS validation or CALPADS IVRUse the error-specific help without clearing the message before its cause is corrected. | The source is fixed — what next?Validate, submit/resend if needed, verify, reconcile, and rerun the original monitor. |
Do not correct the easiest field just because it clears the message.
Preserve the verified event dates and outcome. Correct the source identified by the investigation.
On This Page
Before You Correct
Confirm the investigation has established:
- what actually occurred in the field;
- the date or reporting period being corrected;
- the specific discrepancy or error;
- which source or transaction is wrong; and
- what the corrected result should look like.
Still uncertain?
Return to Data Monitoring Help. A correction should not begin until the owner and intended outcome are clear.
When a current SIRAS or CALPADS system issue is known to affect the error/report, follow the current notice. Do not alter accurate dates or values solely to work around an unresolved system defect.
Correct the Right Source
| Investigation finding | Correction path |
|---|---|
| SIRAS Current data is wrong and future work also needs the corrected value. | Correct Current data. Then determine whether an existing historical archive also contains the wrong value and needs separate correction. |
| Current is correct, but a historical archived transaction is wrong. | Correct or replace the applicable archived transaction without changing what is currently true. |
| The reportable event occurred outside ordinary meeting finalization. | Use the documented reporting workflow, such as Archive for Reporting, when its requirements apply. |
| The meeting occurred but remains open. | Complete the appropriate finalization or Meeting In Progress workflow rather than inventing a new date. |
| A required event remained pending across a reporting date. | Use the applicable Pending As Of workflow with the accurate date, delay code, and label. |
| SIS or CALPADS enrollment is wrong or missing. | Coordinate the enrollment correction. Do not distort SIRAS dates to fit an incorrect enrollment history. |
| CALPADS contains an incorrect or blocking transaction. | Resolve the posted state history as required before resending the accurate SIRAS transaction. |
| CALPADS already contains the correct transaction and SIRAS is trying to send it again unnecessarily. | Review the archive/submission state and avoid creating a duplicate transaction. |
Do not reactivate a finalized IEP meeting merely because CALPADS reports an error.
Most reporting corrections belong in Current data, a dated archive, enrollment, a resubmission, or a specialized reporting workflow.
Error-Specific Routing
| What you are seeing | Use |
|---|---|
| SIRAS displayed a validation message before submission. | SIRAS Built-in Validation System |
| CALPADS rejected a transaction and the IVR is now posted in SIRAS. | CALPADS IVR Errors Posted in SIRAS |
| You need the meaning or first checks for a CALPADS code/message. | CALPADS Error Summary |
| A SIRAS-submitted transaction appears missing/rejected but no new IVR is posted. | CALPADS Submission Log Help |
| You need the full generate/send/import-error/resend workflow. | Reporting data to CALPADS |
Review related errors before fixing one message in isolation.
A downstream error may be caused by an earlier rejected or missing transaction. Correct prerequisite enrollment or ownership problems before repeatedly resending dependent SEDS transactions.
Complete the Correction Cycle
- Correct the source identified by the investigation while preserving the actual event dates.
- Revalidate the student, meeting, or archive as applicable.
- Clear an imported IVR only after its cause has been corrected.
- Prepare the transaction for resend when reporting is required.
- Submit corrected data using Reporting data to CALPADS.
- Verify the job/transaction using CALPADS Submission Log Help or the applicable CALPADS history.
- Reconcile SIRAS and CALPADS when the original concern involved a cross-system mismatch.
- Rerun the query, list, or report that identified the concern.
- Review related records for the same student when the correction may affect another reporting component or monitoring population.
Correction requires CALPADS reporting?
Continue to Reporting data to CALPADS.
Continue to Reporting data to CALPADS.
Verification Standards
| Type of correction | Verify by |
|---|---|
| SIRAS-only operational correction | Confirm the Current record, meeting, assignment, or workflow now represents the verified field event. |
| Archived reporting correction | Confirm the corrected archive contains the intended components and dates before/after resend as appropriate. |
| CALPADS submission | Confirm the transaction was sent and accepted; do not infer success only because the job completed. |
| Cross-system discrepancy | Compare SIRAS and CALPADS after processing and confirm the histories now agree with the verified event. |
| Monitoring-list item | Rerun the original SIRAS query, CALPADS report, or monitoring process and confirm the item disappears or is now correctly represented. |
When to Stop and Ask for Help
Contact SIRAS Support after the first or second informed correction attempt when:
- the verified field history cannot be established;
- multiple archives, duplicate records, transfers, or ownership histories conflict;
- the proposed correction would require changing an accurate finalized record;
- the same error returns after the identified source was corrected and resent;
- a backdated, deletion, specialized CALPADS, or historical reconstruction workflow appears necessary; or
- you are no longer confident that the correction belongs in the source you identified.
Include the SSID, monitoring list/report or complete error code/text, Report Event Date and applicable archive/meeting, relevant CALPADS report/job/screenshot, what actually occurred, which source was identified as incorrect, and correction attempts already completed.
Email: [email protected]
