Education AI agent · SEVIS reporting

SEVIS Reporting Evidence AI Agent

Hold each student's reporting record — the events, the evidence and the clocks — for the designated school official who decides. The school's exposure is administrative; the student's is their presence in the country.

Typical delivery
4–6 weeks
Deployment
Your stack
DSO decides
Never proposes
After launch
Agent Care

What this agent does

Assembles the evidence, never the determination

In

  1. 01

    A student registers, and the per-term position is built before the registration deadline, not after it.

  2. 02

    A registrar drop lands on a Friday, and the clock is dated to the change, not to the day someone found it.

Reason

  1. 03

    A clock starts, and the ledger holds which system, which field, which timestamp, and who saw it first.

  2. 04

    An event is read against 8 CFR 214.3(g)(2) as written, not against what a broadcast message added.

  3. 05

    A reduced course load is authorised, and the basis and the expiry are filed with it, or it does not count.

Decide

  1. 06

    A conduct flag arrives and is refused — only discipline following a criminal conviction is reportable.

  2. 07

    A programme date is held two ways at once, because the rule that would change it is challenged and unresolved.

Out

  1. 08

    An event rests on one system flag alone, and it is marked weak before any deadline reaches the screen.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

The agent assembles the record; the designated school official — a named individual DHS approved — decides what is reported, and reports it.

Example workflow

One student, event to report

  1. 1Reportable event detectedRegistrar drop, address change, employment update or programme-date change
  2. 2Evidence gatheredEach fact with the system it came from, its timestamp and who saw it first
  3. 3Record assembledEvent, evidence and its strength, the clock and what started it, and confidence
  4. 4Controls appliedCorroboration checks, authorisation-basis checks, the refusal list and confidence threshold

No human action required

Stages 1 to 4 run unaided, and none of them determines a status or proposes a termination — the agent is assembling, and the official lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the designated school official.

Low confidence

Adds a principal-official read first.

Official review

The record is held with its evidence, the strength of that evidence and the clock.

Review · Correct · Send to the PDSO

Reviewed — the official reports

  1. 6Office case record updatedOnly where write access and approval policy allow it
  2. 7Outcome evaluatedEvidence sufficiency, clock accuracy, corrections raised and reports not made

Corrections

Every official correction is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Proposing a status determination, in any form an official could act on.
    • Proposing a termination — not as a draft, a score or a pre-filled field.
    • Reporting anything to SEVIS, or entering a record for an official.
    • Issuing, signing or updating a Form I-20.
  • Automation boundary

    Agent acts unaided

    • ✓Assemble the per-event record and name the system each fact came from.
    • ✓Run each clock from the change, and record what started it.
    • ✓Mark the strength of the evidence, and show it beside the clock.
    • ✓Show what is missing, and keep gather more as a tracked outcome.

    Wrong after a report and a student can lose their stay within days; in 2025 the fix was litigation.

    • Matching a student against any criminal or enforcement data source, ever.
    • Authorising a reduced course load, CPT, OPT or a shortened programme.
    • Ranking, scoring or risk-classifying students in any way.
  • Changes to event rules, clock configuration or review thresholds.

Example output

One student record, annotated

Everything the agent assembles is attached to the system it came from.

Reporting-record output · single student

Illustrative example
Student
F-1, third term
Assembled finding
A registrar drop is the only support behind a failure-to-maintain event
Clock
Day 9 of 21
Rule applied
8 CFR 214.3(g)(2)
Confidence
87%
Evidence strength
Weak — one system, uncorroborated

As received

Taken from the registrar system as it stands — our enrollment and records agent owns that system, not this one, and nothing on this side is inferred.

Evidence used

  • Registrar status flag
  • Term registration record
  • No corroborating source

Why this flag

One system said so and nothing else did — the strength is the finding, and the clock is not a reason to act.

What the score decides

Below the configured threshold the record picks up a principal-official read before the official sees it.

Action

ReviewCorrectSend to the PDSO

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every student

From the registrar system

03Assembling

Assemble against the rule as written

Draw on the events on file, the clocks and the evidence under each. The shipped advising agent routes anything touching immigration to the named professional, and this page is what that referral defers to — the professional is a designated school official DHS has approved by name.

01Approved path

Gather more is the default

Routine event capture and clock arithmetic arrive already done.

02Human review

Show the weak evidence louder than the clock

Under-evidenced events are marked as loudly as missed deadlines. In March 2025 a mass match of student records against a criminal database produced terminations a federal judge said from the bench on 29 April 2025 all present agreed were arbitrary and capricious.

04

Build an evidence trail

The event, the evidence beneath it and the official who reported stay on the record.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • SEVIS and SEVP

    • SEVIS RTI batch
    • Form I-17 and I-20 records
  • Student information

    • Banner
    • PeopleSoft
    • Workday Student
    • Colleague
  • International office

    • Terra Dotta
    • Sunapsis
    • Case notes and authorisations

Agent

SEVIS reporting evidence

  • Reads the record
  • Assembles the evidence
  • Holds for the official
  • Registrar and HR

    • Registration and term records
    • Employment and payroll records
  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the record

Six barriers taken in turn. What clears the last of them is written into the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeHold the record at unreported when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, event-rule and clock-configuration changes.Track
L4TraceabilityRecord the events, the evidence, its source, the flags and the review time.Record
L3Official reviewHolds the record for the designated school official; it governs what is shown, not whether a report is right.Gate
L2Policy guardrailsTest each event against the rule as written and the refusal list; a failure returns the event.Restrict
L1Confidence thresholdsRoute low-confidence events to a principal-official read first.Require review
Model coreRecord produced — event, evidence, its strength, the clock and confidence
L1 – L2
Test whether an event may stand
L3
Puts the record in the official's hands
L4 – L5
Keep the event and the evidence behind it
L6
Holds the record at unreported when signals degrade

How Nestack evaluates it

Evaluate the whole reporting record — not only the event at the end.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the record the official reads

  1. E1Final-output evaluationDid every fact in the record carry the system it came from?
  2. E2Step-level evaluationDid the agent use the right student, rule text and clock configuration?
  3. E3Tool evaluationDid it read the correct student and write the correct record?
  4. E4Confidence calibrationDo low-confidence events actually attract more official corrections?
  5. E5Slice evaluationHow far apart do evidence rates sit across specific event classes?
  6. E6Business outcomeHow many events were held for more evidence, and how many aged out?

Floor — the report the official stands behind

Failure modes

Where each failure originates in the agent

Seven failure modes, placed at the lifecycle stage each one starts in.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • HN-03

      Event never surfaced

      A registrar drop sat in an export nobody owned.

    Stage gathers

    Events, evidence, source systems and the clocks

  2. 02 · Reasoning

    2 modes

    • HN-04

      Status inferred

      An event is read as a status conclusion it cannot carry.

    • HN-06

      Clock read as reason

      Days remaining are treated as evidence a report is due.

    Stage proposes

    Event, evidence, strength, clock and confidence

  3. 03 · Tool / write

    2 modes

    • HN-02

      Queue sorted by clock

      Days remaining outrank evidence strength on screen.

    • HN-05

      Conduct flag admitted

      An internal discipline matter enters without a conviction.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • HN-01

      Weak evidence unmarked

      A single system flag is presented as a settled fact.

    Stage returns

    The record the official reports from, and answers for

  5. 05 · Change / Version

    1 mode

    • HN-07

      Silent rule drift

      A configuration change widens what counts as reportable.

    Stage tracks

    Model, prompt, event rules and clock config

  • Sev-1 · a determination is proposed
  • Sev-2 · a weak event is reported
  • Sev-3 · source degrades, record to review
See the complete Education failure-mode catalogue

Affected slices

One event class can carry most of the gaps

A term-level evidence-sufficiency figure can read sound while a single event class holds most of the thin records and the unstarted clocks. Nestack reports the gap rate by event class, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Failure-to-maintain events9.0%3.7×Review
Reduced course load events6.6%2.7×Review
OPT and STEM OPT changes4.2%1.7×Watch
Name and address changes1.9%0.8×Normal

Bar: gap-rate lift vs. the name-and-address-change baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

An under-evidenced report ends as a test

The loop shuts when the under-evidenced report is a regression case. That suite is what the next event worked is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Gap rate rises in one event class.

  2. 02

    Diagnose

    The address change that was reported before anyone checked it was real is read back through its evidence and its source until the cause narrows to one.

  3. 03

    Improve

    Any change ships with a number, and the events attach to it.

  4. 04

    Verify

    One event case still failing is enough to hold the release.

  5. 05

    Learn

    One case joins the suite, one line joins the reporting record.

  6. Learn → Detect

    The return edge. The next detection runs against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, reporting workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Reporting workflow discovery and refusal boundary.Week 1
  2. 02SEVIS and student-system assessment.Week 1, Week 2
  3. 03Event, clock and evidence-strength rule mapping.Week 1, Week 2
  4. 04Event and evidence ingestion.Week 2
  5. 05Clock arithmetic and source binding.Week 2, Week 3
  6. 06Confidence scoring and event routing.Week 3
  7. 07Designated-official review workflow.Week 3, Week 4
  8. 08Student-system and SEVIS integration.Week 5
  9. 09Evidence and clock cases.Week 4, Week 5
  10. 10Guardrails and reporting controls.Week 4
  11. 11Event-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne campus, one termProductionProduction SEVIS and student systemsAdvancedMultiple campuses / programmes
Introduced at Pilot
Evidence assembly to the rule as written✓✓✓
Designated-official review✓✓✓
Evidence-sufficiency baseline✓✓✓
Introduced at Production
Reporting by event class—✓✓
Review workflow in your systems—✓✓
Approved record write-back—✓✓
Student-system integration—✓✓
Introduced at Advanced
Multi-programme event rules——✓
Multi-stage official review——✓
High student volume——✓
Multi-campus reporting controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, student volume, review controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your event sources and where each one lands

    Event and evidence ingestion, and source binding

    Week 1
  2. 02Representative records from a past term

    Evidence-sufficiency baseline and clock normalisation

    Week 2
  3. 03Your rule register and where each belief came from

    Event, clock and evidence-strength rule mapping

    Week 1
  4. 04Access to relevant APIs, feeds or exports

    SEVIS and student-system review, then integration setup

    Week 2
  5. 05Reports you would not want defended

    Evidence cases and failure-mode testing

    Week 4
  6. 06What no report may infer

    Confidence scoring, event routing, guardrails and reporting controls

    Week 3
  7. 07The designated school officials who decide

    Official review workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Time on the work fixes every width drawn on here, and that is what puts two bands into week five.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Reporting workflow discovery, rule mapping and the refusal boundary

W2Source integration and the evidence-sufficiency baseline

W3Clock arithmetic, evidence strength and review controls

W4Evaluation suite, evidence cases and failure-mode testing

W5SEVIS and student-system integration, a pilot term and targeted corrections

W6One term run under the designated school official, then Agent Care handover

Reading the band
Each bar sits only on the weeks its work is named in. The fifth-week overlap is real, not padding.
At the end of W6
Once the term validates, Agent Care assumes the agent.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Education AI agent

Build a SEVIS reporting agent around the official who decides.

Show us your event sources, your clocks and who holds the designation. The record has to survive a withdrawal notice with 30 days to answer, a student reading back the day their record changed, and a rule change still before a court.

Typical delivery
4–6 weeks
Deployment
Your SEVIS and student stack
DSO decides
Never proposes
After launch
Agent Care available

Nestack Agents · SEVIS reporting evidence

AGT-ED-13 · Agent Care available after launch

Build a SEVIS reporting agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your students

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.