Data Monitoring Help: Investigate a Questionable Record

Aug 23, 2026

Investigate before changing data Use this page when a student, transaction, count, or compliance item appears on a monitoring list and the reason is not immediately clear. The goal is to establish what actually happened, find where the record first stops representing it correctly, and determine where the correction belongs.

Data Monitoring Journey Learn · Plan

Monitor Investigate Correct Submit Verify Reconcile & Repeat

You are here: Investigate.

What Do You Need to Figure Out?

What exactly is the problem? Define the concern, the alert/report that exposed it, and the date that must be correct.

What evidence best establishes what happened? Compare field/source documents, SIS, SIRAS, and CALPADS.

What actually happened, and when? Put the relevant enrollment, eligibility/participation, meeting, plan, service, transfer, and exit events in date order.

Where do the records first disagree? Find the first meaningful point where a system or dated transaction stops matching the verified event.

Where should the correction be made? Identify the system/record that must change first, then identify the role authorized to make that change.

Am I ready to correct it? Proceed to the correction process only after the event, date, reason, correction location, and responsible role are understood.

No guessing.
If one item appears wrong, do not correct only that field until you understand whether related Current data, archived history, SIS/SENR, or CALPADS reporting also needs attention. If the history is not clear, ask SIRAS Support for help before changing data.

Three sides of the story

SIRAS side: what SIRAS Current/MIS Summary, IEP Manager, and archived history show.
CALPADS/reporting side: what the district SIS/SENR and CALPADS SEDS/reporting history show.
Field side: what people and source documents establish actually happened.

These are three perspectives on the same student history. Section 2 separates them into four evidence sources—Field, SIS, SIRAS, and CALPADS—so each source can be checked independently.

Correction location: The system, record, transaction, or workflow state that needs to change—for example SIRAS Current, a SIRAS archive, district SIS/SENR source data, or posted CALPADS history.
Responsible role: The user/staff role authorized to make the needed change. The person is not the “owner” of the bad data; they are the person responsible for correcting the appropriate source or completing the required workflow.

Typical role handoff:
A SIRAS provider may establish what happened in the field and create/update an IEP meeting or PLAN information within their permitted workflow. A SEDS Coordinator typically monitors and reports SEDS transactions to CALPADS. SIS/enrollment staff typically correct and report SENR enrollment information. Exact permissions and local responsibilities vary by district.

On This Page

Define the Question Review Four Sources Build the Timeline Locate the Difference Historical SIRAS Evidence Identify Correction Location & Role Prioritize Findings Investigation Complete When to Escalate

1. Define the What and When?

Start with two questions: What is the concern? and As of what date should the answer be correct? The concern tells you what to investigate. The as-of date defines the scope of the history you need to reconstruct.

Examples:

Plan Adoption: Why is this student on the Plan Adoption Required list today? The student arrived this week—do the incoming records and current situation actually meet Plan Adoption criteria?
Overdue meeting: Why does a CALPADS report show this meeting as overdue? Is the meeting truly overdue and needs immediate follow-up, or is a known historical meeting/evaluation date missing from SIRAS?
Inactive archive: Why is this inactive student still appearing as requiring an archive? Was the inactive event never archived, or was the Current inactive date changed after a different date was archived?
Certification population: Why was this student missing from a prior June certification population? Was the SIRAS record not created or reportable before the applicable CALPADS certification deadline?

Monitoring questions often depend on a specific as-of date, Report Event Date, meeting date, enrollment date, Census Day, or certification period. Keep in mind thresholds of when a student turned 3 or 5 years old.

Determine the expected result.
Before deciding what to change, state what the record or report should show if the verified event were represented correctly. That expected result becomes the target of the investigation. If fixing this one data element, are there other things that we need to research as well.

2. Review the Four Sources

Source	What to establish
In the Field / source-document evidence	What the IEP team, enrollment staff, service providers, family records, signed documents, incoming records, and other reliable source documents establish actually occurred.
SIS	Enrollment, identifiers, demographics, attendance, discipline, and other district-controlled information relevant to the question.
SIRAS	Current status, MIS data, meetings, plans, services, archived reporting transactions, assignments, and local workflow history.
CALPADS	Posted enrollment and SEDS transactions, certification reports, errors, warnings, and discrepancy information.

No system view wins automatically—verify.
SIS, SIRAS, and CALPADS can each be internally consistent while still being incomplete, outdated, or based on an earlier event. Use verified field/source evidence as appropriate to establish what happened. Then determine which system or dated transaction does not represent that event correctly and correct the affected source(s) in the proper order.

Example — GERR0005 on a PLAN transaction:
First verify the student's SENR enrollment history in CALPADS. If SENR is missing or has the wrong start date, the SIS/enrollment side must be corrected first. If SENR is correct, verify the district enrollment date in SIRAS Current and in the applicable archived transaction. Correct the SIRAS source/history as needed, then resend the Plan Adoption transaction from SIRAS. The investigation determines which part of this sequence actually applies.

3. Build the Timeline

Think of the events that happened, play them forward to today:

district enrollment and exit;
special education eligibility/participation start or exit;
referral and consent;
meeting and evaluation dates;
plan effective dates;
service start and end dates;
transfer or Plan Adoption activity; and
the date of any archived SIRAS or posted CALPADS transaction being reviewed.

Looking at each event back to when data was correct, was the reported data correct by the time they got to your district.

If not, then you might be inheriting an error that other district may need to if.

If it is then we need to keep stepping thru events in the field comparing to what was entered into SIRAS.

Looking at things well in the future from when the error is represented in the past also is a way of looking at things that takes getting used to.

For help distinguishing Current from dated reporting history, see Archived Transactions: Current Data, Components, and Reporting Status.

4. Locate the Difference

Compare the verified event/timeline with what SIS, SIRAS, and CALPADS show. Identify the first meaningful point where the record stops matching what actually happened. The monitoring alert may appear later in the chain than the original cause.

What you find	What it may mean	What to check next
SIS enrollment does not match SIRAS district enrollment.	SIRAS may not have received the correct/new district enrollment information, or the SIS source itself may be wrong.	Verify the district enrollment event and SIS value first, then check the applicable SIS/SIRAS integration or update path.
SIRAS Current does not match what is true now, but prior history is correct.	Someone changed data on the MIS summary page in error. Someone may have 'fixed' data on the MIS Summary page.	Check with staff in the field as to what the recently changed data point should represent. Ex. Program Setting, looking at age and grade. Age as of today vs age as of report date.
SIRAS Current is correct now, but an archived transaction contains the wrong historical value.	Are we sure it is wrong? Data changes happen. If we know an archive, as of the report event date has wrong information. That is different.	Sometimes program setting isn't updated as soon as it should be and misses getting reported automatically. It is ok to open a previously reported transaction to fix it and resend it to update CALPADS.
SIRAS shows a reporting status of Complete, but the expected transaction is absent from CALPADS.	The CALPADS transaction may have been removed later, or the SIRAS reporting status may not reflect what actually posted.	Verify the SIRAS archive/submission history and the CALPADS posted history before changing status or resending.
CALPADS contains a transaction that does not represent the verified event.	The posted state history is wrong, but the upstream source may be SIRAS Current, an archive, a prior transaction, SIS/SENR, or another LEA's history.	Identify and correct the earliest upstream source/transaction that is wrong, then use the proper correction/resubmission path to bring CALPADS into alignment.
SIS, SIRAS, and CALPADS agree, but verified field/source evidence says something different occurred.	The same inaccurate value may have propagated into more than one system.	Return to the source documents/field evidence, establish the correct event, then correct the earliest authoritative source before updating downstream systems.

Useful rule: correct upstream first.
When the same incorrect value appears in multiple places, identify where the error entered the chain. Correct that source first, then propagate or report the verified value downstream as required.

When You Need Historical SIRAS Evidence

Historical search produces evidence, not the answer by itself. After finding the archive, compare it with SIS/SENR, SIRAS Current, CALPADS, and information from the field before deciding what actually happened and which record/system needs correction.

Use Find One Historical or Out-of-District SIRAS Record when the question is about one student's prior archive.
Use Advanced Historical Queries for Archived Student Data when you need to build a historical archive set, search a date range, or compare archived and Current values.
Use Reconstruct a Historical SIRAS Population Estimate when an actual point-in-time snapshot was missed and a larger historical population must be estimated.

If Current data does not explain the discrepancy, review the archived SIRAS history before deciding which system or transaction is wrong.

5. Identify Where the Correction Belongs

Do not begin the correction until you can answer two separate questions:

Correction location: Which system, record, transaction, or workflow state must change?
Responsible role: Who has the permission and appropriate workflow to make that change?

The correction location and the responsible person are not the same thing.
For example, the incorrect value may be in SIRAS Current, while the person authorized to correct it could be a provider, SPED clerk, SEDS Coordinator, or administrator depending on the field, record state, permissions, and local workflow.

Correction location	When this is the problem	Responsible role / next action
District SIS / district source data	District-controlled enrollment, demographics, identifiers, or other SIS-managed information is wrong or missing.	The appropriate district enrollment/data staff correct the source. Then verify the SIRAS integration/update path before manually duplicating the same correction in SIRAS.
SIRAS Current	The student's current MIS/program information does not represent what is true now, while the historical record being reviewed is otherwise correct.	An authorized SIRAS user corrects Current. Who can edit the field depends on role, permissions, record state, and whether the field is locked.
SIRAS archived transaction	A dated historical transaction contains an incorrect value even though Current may now be correct.	Staff with the appropriate SEDS/CALPADS authority review the archive correction/replacement path and resend when required. See User Access Roles for access context.
SIRAS meeting / workflow state	The data may be correct, but an open/closed/finalized meeting, required event, or workflow state is preventing the expected next action.	The user or administrator responsible for that workflow completes/corrects the appropriate meeting or event. If the verified workflow is correct but SIRAS still blocks it, escalate with the exact state and result.
CALPADS posted history	The posted state history contains an incorrect or blocking transaction.	Determine whether the correction begins in SIRAS, SIS/SENR, CALPADS, or requires action by another LEA. Correct the upstream source/transaction first, then use the appropriate delete/replace/resubmit process.

No safe correction location yet?
Stop. If the verified event cannot be established or the records conflict too strongly, there is no safe correction yet. Gather more evidence or escalate rather than choosing a system or person just to move the item forward.

Correction location and responsible role known?
Continue to Process for Error Resolution.

Prioritize Findings

Priority	Examples	Expected action
Immediate	Wrong student access, duplicate identity, invalid transfer, or an event represented incorrectly in a way that can affect other processing.	Pause related processing, establish the correct history, and coordinate the correction.
Reporting blocker	Posted IVR, rejected transaction, missing prerequisite transaction, or fatal certification error.	Resolve before the applicable reporting or certification deadline.
Compliance risk	Overdue event, missing delay reason, missing Pending As Of, open meeting, or incomplete plan/service reporting.	Verify the event and identify the accurate follow-up/reporting path.
Warning / anomaly	Unexpected count, age/grade difference, unusual service pattern, or cross-system mismatch that does not block submission.	Review and document; correct only when the underlying data is inaccurate.

Investigation Complete: Hand Off to Correction

Investigation is complete when you can answer the relevant related questions like:

What actually happened in the field? This narrative is data entry in SIRAS or SIS.
What date or reporting period is being evaluated? If age sensitive, pay attention to age as of effective date.
Why does the monitoring item appear?
Which system, record, or transaction must be corrected first?
Which role is authorized to make that correction?
What downstream update, archive replacement, re-submission, or verification will be required afterward?

At that point, use Process for Error Resolution to make the verified correction, submit/resend when required, verify acceptance, and rerun the original monitoring query or report.

When to Escalate

Contact SIRAS Support when:

the real-world event cannot be reconstructed from available records;
SIRAS and CALPADS contain conflicting historical transactions requiring verification.
a duplicate record, identity, access, or transfer issue is involved; Changing of birthdate or SSID requires assistance.
the correction appears to require a specialized backdated or archive workflow;
the proposed solution would require changing an accurate finalized record;
you know where the problem is but the authorized workflow still will not allow the correction; or
you still cannot identify the correction location or responsible role after completing the investigation.

Include the SSID, the monitoring list/report or error being investigated, the relevant dates, what the verified field/source evidence shows, what SIS/SIRAS/CALPADS show, and the exact correction path or system state that remains unclear.

Return to LEA Data Monitoring Tasks