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
- 01
A student registers, and the per-term position is built before the registration deadline, not after it.
- 02
A registrar drop lands on a Friday, and the clock is dated to the change, not to the day someone found it.
Reason
- 03
A clock starts, and the ledger holds which system, which field, which timestamp, and who saw it first.
- 04
An event is read against 8 CFR 214.3(g)(2) as written, not against what a broadcast message added.
- 05
A reduced course load is authorised, and the basis and the expiry are filed with it, or it does not count.
Decide
- 06
A conduct flag arrives and is refused — only discipline following a criminal conviction is reportable.
- 07
A programme date is held two ways at once, because the rule that would change it is challenged and unresolved.
Out
- 08
An event rests on one system flag alone, and it is marked weak before any deadline reaches the screen.
- 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
- 1Reportable event detectedRegistrar drop, address change, employment update or programme-date change
- 2Evidence gatheredEach fact with the system it came from, its timestamp and who saw it first
- 3Record assembledEvent, evidence and its strength, the clock and what started it, and confidence
- 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.
Goes to the designated school official.
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
- 6Office case record updatedOnly where write access and approval policy allow it
- 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 PDSOValue
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
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.
Gather more is the default
Routine event capture and clock arithmetic arrive already done.
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.
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
- 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
- E1Final-output evaluationDid every fact in the record carry the system it came from?
- E2Step-level evaluationDid the agent use the right student, rule text and clock configuration?
- E3Tool evaluationDid it read the correct student and write the correct record?
- E4Confidence calibrationDo low-confidence events actually attract more official corrections?
- E5Slice evaluationHow far apart do evidence rates sit across specific event classes?
- 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 →
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
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
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
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
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
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| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Failure-to-maintain events | 9.0% | 3.7× | Review | |
| Reduced course load events | 6.6% | 2.7× | Review | |
| OPT and STEM OPT changes | 4.2% | 1.7× | Watch | |
| Name and address changes | 1.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
- 01
Detect
Gap rate rises in one event class.
- 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.
- 03
Improve
Any change ships with a number, and the events attach to it.
- 04
Verify
One event case still failing is enough to hold the release.
- 05
Learn
One case joins the suite, one line joins the reporting record.
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
- 01Reporting workflow discovery and refusal boundary.Week 1
- 02SEVIS and student-system assessment.Week 1, Week 2
- 03Event, clock and evidence-strength rule mapping.Week 1, Week 2
- 04Event and evidence ingestion.Week 2
- 05Clock arithmetic and source binding.Week 2, Week 3
- 06Confidence scoring and event routing.Week 3
- 07Designated-official review workflow.Week 3, Week 4
- 08Student-system and SEVIS integration.Week 5
- 09Evidence and clock cases.Week 4, Week 5
- 10Guardrails and reporting controls.Week 4
- 11Event-trail instrumentation.Week 5, Week 6
- 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 tier | PilotOne campus, one term | ProductionProduction SEVIS and student systems | AdvancedMultiple 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 price | From $5,000 | From $8,000 | Custom 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.
You bring
We build with it
01Your event sources and where each one lands
→Event and evidence ingestion, and source binding
Week 102Representative records from a past term
→Evidence-sufficiency baseline and clock normalisation
Week 203Your rule register and where each belief came from
→Event, clock and evidence-strength rule mapping
Week 104Access to relevant APIs, feeds or exports
→SEVIS and student-system review, then integration setup
Week 205Reports you would not want defended
→Evidence cases and failure-mode testing
Week 406What no report may infer
→Confidence scoring, event routing, guardrails and reporting controls
Week 307The 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
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- 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
