Nexus

Appearance

MOSIS Operational Data Platform ​

StatusUrgencyImpactCreated

Nexus should support daily operational ingestion from Infinite Campus and other student information systems, then use that data to generate Missouri MOSIS files, exception reports, and DESE-style district and school grade-card analytics.

Current Context ​

Nexus already has the beginning of a canonical education model:

  • People, identities, and contacts live in the Census module.
  • Schools, school years, calendars, enrollments, employments, and employment assignments live in the Education module.
  • Tenants and current education context already exist as platform scope concepts.

DESE treats Core Data and MOSIS as linked collection systems. MOSIS has ID Assignment and Data Collection components, with six standard collection cycles during the year: August, October, December, February, April, and June. DESE also publishes year-specific file layouts, business rules, and templates. As of July 4, 2026, the current planning target is the 2026-27 layout set.

References:

Product Outcome ​

Daily operators should be able to:

  • Pull or upload SIS data every day.
  • See whether source SIS data can produce clean MOSIS files.
  • Generate MOSIS files for a selected school year, cycle, school, and layout.
  • Review row-level and field-level exceptions before submission.
  • Compare SIS values, Nexus canonical values, MOSIS extract values, and post-submission corrections.
  • Explore district, building, grade, subgroup, attendance, discipline, course, graduation, educator, and assessment indicators in datamarts that mimic DESE grade-card reporting patterns.

Proposed Architecture ​

1. SIS source layer ​

Create a source-system boundary that keeps imported SIS records auditable and repeatable.

Candidate tables:

  • integration.source_systems
  • integration.source_connections
  • integration.ingestion_runs
  • integration.ingestion_files
  • integration.source_entities
  • integration.source_records
  • integration.source_record_errors

Initial source systems:

  • Infinite Campus direct SQL read replica or reporting database.
  • Infinite Campus extract files.
  • Generic CSV or delimited SIS import.
  • Future API connectors where districts expose supported endpoints.

Important behavior:

  • Store the original source payload or file reference.
  • Store source query identity, source record identity, source timestamps, checksum, and import run.
  • Support replaying a run into canonical Nexus records.
  • Do not overwrite canonical education records until mapping and validation rules pass.
  • Keep direct SQL access read-only, least-privileged, and pointed at a reporting database or replica when possible.
  • Version SQL source queries alongside mapping metadata so field derivations remain explainable.

Direct Infinite Campus SQL should be treated as the preferred high-fidelity connector when available. The ingestion run should snapshot query results into Nexus staging tables first, then map from staging into canonical records. This keeps downstream MOSIS generation deterministic even if SIS data changes during the day.

2. Canonical education layer ​

Extend the existing Education and Census models so Nexus can represent the data MOSIS and grade-card marts need.

Likely additions:

  • Student demographics, state IDs, local IDs, race and ethnicity, gender, birth date, residency, and program participation.
  • Enrollment entry, exit, grade level, attendance center, calendar, attendance minutes or hours, full-time equivalency, and mobility facts.
  • Course sections, terms, educators, educator assignments, student course assignments, credits, marks, and completion outcomes.
  • Discipline incidents, actions, durations, locations, and state-reportable flags.
  • Assessment precodes and result facts.
  • Graduation cohort, follow-up, postsecondary, military, employment, and CTE participation facts.
  • District and school directory identifiers needed for DESE reporting.

Design rule: keep source-specific names out of canonical tables unless they are true business concepts. Infinite Campus field names belong in mapping metadata, not in the core model.

3. MOSIS specification layer ​

MOSIS generation should be metadata-driven and school-year-versioned.

Candidate tables:

  • reporting.mosis_layouts
  • reporting.mosis_layout_fields
  • reporting.mosis_code_sets
  • reporting.mosis_business_rules
  • reporting.mosis_extract_runs
  • reporting.mosis_extract_rows
  • reporting.mosis_extract_values
  • reporting.mosis_validation_results

Key dimensions:

  • School year, such as 2026-27.
  • Cycle, such as August, October, December, February, April, June, or Assessment Precode.
  • Layout, such as Student Core, Educator Core, Student Enrollment and Attendance, School Calendar Header, School Calendar Days, Discipline, Course Assignment, Student Assignment, Student Course Completion, CTSO, ASVAB, or MOSIS ID Batch.
  • Field order, required status, type, width or format, code set, derivation rule, and null handling.

Generation should produce a run artifact with:

  • Input snapshot.
  • Layout version.
  • Generated file.
  • Row count.
  • Blocking errors.
  • Warnings.
  • User, timestamp, and tenant context.

4. Validation and exception layer ​

Operators need exception reports before they generate final MOSIS files.

Exception types:

  • Missing required values.
  • Invalid code set values.
  • Cross-field business-rule failures.
  • Invalid date ranges.
  • Student with enrollment but no MOSIS ID.
  • Calendar-day or attendance mismatch.
  • Course assignment without valid educator assignment.
  • Discipline row missing state-reportable details.
  • Student present in SIS but excluded from MOSIS, or present in MOSIS mart but no longer active in SIS.

Each exception should include:

  • Entity type and record ID.
  • Source system and source record key.
  • MOSIS cycle, layout, and field when applicable.
  • Severity.
  • Suggested fix owner.
  • Current value, expected shape, and derivation trace.
  • Suppression or resolution status.

5. Datamart layer ​

Create read-optimized marts for exploration and grade-card-style reporting.

Candidate schemas:

  • mart.sis_quality_*
  • mart.mosis_readiness_*
  • mart.mosis_extract_*
  • mart.grade_card_*

Initial marts:

  • Enrollment by school, grade, subgroup, and date.
  • Attendance and attendance-rate facts.
  • Discipline incidents and exclusionary action facts.
  • Course participation, completion, credit, and educator assignment facts.
  • Graduation cohort and follow-up facts.
  • Assessment participation and performance facts.
  • MOSIS exception trend by cycle, layout, field, school, and owner.

Grade-card style reporting should be implemented as transparent indicator definitions rather than opaque dashboard calculations.

6. User workflows ​

Daily operations:

  1. Run or schedule SIS ingestion.
  2. Review ingestion health and record deltas.
  3. Map clean records into canonical Nexus entities.
  4. Refresh MOSIS readiness marts.
  5. Review blocking exceptions by school, owner, layout, and field.
  6. Generate daily MOSIS files for selected cycles/layouts.
  7. Store extract artifacts and validation history.

Analysis:

  1. Pick school year, district, building, grade, subgroup, and indicator.
  2. Compare SIS source, Nexus canonical, MOSIS extract, and derived mart values.
  3. Drill from aggregate metric to student, course, incident, attendance, or educator records.
  4. Export exception lists for correction work.

Implementation Phases ​

Phase 1: Foundations ​

  • Add integration schema and ingestion run tracking.
  • Support direct SQL ingestion from Infinite Campus plus manual CSV uploads for Infinite Campus extracts and generic SIS files.
  • Store raw source rows and normalized source entity identities.
  • Add basic mapping configuration from source fields to Nexus canonical fields.

Phase 2: Canonical education expansion ​

  • Extend student, enrollment, calendar, grade-level, attendance, course, educator, and discipline models.
  • Add district and school state identifiers.
  • Add source-to-canonical reconciliation views.

Phase 3: MOSIS MVP ​

  • Implement MOSIS ID Batch and Student Core first.
  • Add layout-field metadata for the current school year.
  • Generate files from a selected extract run.
  • Store validation results and generated artifacts.

Phase 4: Daily readiness and exceptions ​

  • Add scheduled ingestion.
  • Add daily MOSIS readiness checks.
  • Add exception ownership, suppression, resolution status, and trend reporting.
  • Build operator views for fixing data before submission.

Phase 5: DESE-style marts ​

  • Build grade-card indicator definitions.
  • Add district, school, grade, subgroup, and time-sliced aggregates.
  • Support drill-through to source and canonical records.
  • Add year-over-year comparisons once historical loads are available.

Open Questions ​

  • Which Infinite Campus database target is available first: production read-only, reporting database, replicated database, or warehouse?
  • Which Infinite Campus export mechanisms should remain supported as fallbacks: OneRoster, ad hoc CSV extracts, data warehouse extracts, or API access?
  • Should generated MOSIS files be stored in Postgres, object storage, or filesystem-backed artifacts?
  • Which MOSIS layouts are highest priority after ID Batch and Student Core?
  • Does Nexus need to submit files directly, or only generate and validate files for manual upload to DESE?
  • Which DESE grade-card indicators should be considered legally authoritative versus internal approximations?
  • How should corrections made in Nexus flow back to Infinite Campus, if at all?

Nexus by McGuire Technology

Version 26.7.3