This article describes Current data for the Special Education designation. Current/MIS represents what SIRAS understands to be true now for the student's SPED record and supplies context for later meetings, monitoring, and SEDS reporting.
504 and SST have their own Summary Page and Forms Manager behavior; do not assume the SPED Current/archive lifecycle applies to those designations.
IEP Manager can hold proposed changes; Current/MIS holds the data now in effect; archived transactions preserve dated reporting history.
Contents
| Current Data | Meeting Data |
| Meeting → Current → Archive | How Current Supplies Components |
| Archived Data | Timely Current & Historical Integrity |
Current Data – What SIRAS Knows Now
The MIS Summary contains the current student, status, plan, service, contact, provider, enrollment, and reporting information.
- Current populates a new IEP Manager event when the meeting is opened.
- Current drives searches, lists, caseloads, and census-day extracts.
- Current is copied into a manual Archive for Reporting transaction.
- Current should reflect the latest verified field information.
For Active, Pending, and Inactive meanings, see SIRAS Record Status.
Meeting Data – Proposed or In-Progress Changes
When full agreement has not automatically resolved every proposed data item, staff use Pending Changes to decide which meeting changes should actually return to Current/MIS. See IEP Manager Pending Changes and Pending in SIRAS.
Information being developed in IEP Manager represents proposed or in-progress changes. Entering a proposed plan or service in the meeting does not automatically make it Current.
The selected Parent Response and the meeting finalization workflow determine which proposed changes are allowed to become Current.
| Meeting outcome / response | Current-data effect |
|---|---|
| Accepts the Plan (Signed Consent) | Applicable approved pending plan changes become Current. This can include the accepted service set, which then appears on the MIS Summary. |
| Awaiting Response | The meeting remains open; proposed plan changes remain pending and do not become Current yet. |
| Parent Contacted, No Response | The meeting may close when the documented workflow permits, but a new unaccepted PLAN/SERV is not created merely because the meeting was closed. |
| Does not accept the plan / Stay-Put / No Plan | The proposed plan does not replace the last agreed-to Current plan. Unaccepted plan/service changes should not become the student's new Current participating service set. |
| Partial consent | Only the approved portions should be applied. Use the Parent Response guidance and verify Current carefully after finalization. |
For the exact effect of each response, see Parent Response - Impact Table. For disagreement and partial-consent procedures, see Parent Response - Steps for Disagreements.
Verify the selected Parent Response and then verify the MIS Summary, services, goals, and archived transaction according to that response.
From an Accepted Meeting to Current Data and an Archived Transaction
For an accepted plan, the basic data path is:
Services follow this same model. Services developed in the meeting are proposed until the response/finalization workflow applies the accepted service information to Current. The service section on the MIS Summary then represents the student's current plan-service information.
When the event is archived, the applicable reportable plan/service information is preserved in the transaction. A reportable PLAN can therefore have associated SERV records.
The service rows on the MIS Summary describe what the student's plan provides. Service Logs document delivered service sessions. Entering a Service Log does not itself create or replace a CALPADS SERV component.
How Current Data Supplies Transaction Components
| Current information | Archived component relationship |
|---|---|
| Status, eligibility, participation, inactive date and reason | SWDS |
| Referral, consent, evaluation, Last Annual, Last Evaluation and outcome information | MEET |
| Plan type, Plan Effective Date, program setting and related plan information | PLAN |
| Regular services associated with the plan | SERV |
To understand which components belong in an archive, see Archived Transaction Components: SWDS, MEET, PLAN, and SERV.
Archived Data – Historical Transaction
An archived transaction is a dated snapshot of the applicable Current or finalized meeting information. Archives may be created by:
- finalizing an IEP Manager event;
- using Archive for Reporting; or
- a specialized workflow such as Pending As Of, Plan Adoption, or a reportable inactive status change.
See Archived Transactions: Current Data, Components, and Reporting Status.
Keep Current Timely Without Rewriting History
When something changes:
- update Current using the real field date and verified information;
- finalize the meeting or create the required archive;
- confirm that the transaction was submitted and accepted; and
- correct Current and the archive separately when they contain different errors.
Keep Current accurate now while preserving each reportable event through the appropriate archive.
