The short version
Three forces converged and turned a full-platform replacement of Illuminate from a someday project into a now project.
Accessibility. The DOJ's ADA Title II rule requires public entities — including state colleges, state universities, community colleges, and system offices — to meet WCAG 2.1 Level AA for their web content and mobile apps. State and local government entities with a total population of 50,000 or more must comply by April 26, 2027; smaller entities and special-district governments by April 26, 2028. The obligation reaches the third-party software embedded in your digital environment, which means it reaches us. Illuminate's 2015-era front end was not built to that bar and cannot be retrofitted to it economically.
Security. N2N's SOC 2 program raised the floor on tenant isolation, audit evidence, secrets management, and least-privilege access. Illuminate meets its controls, but slowly, and with manual effort at every step. Today's threat environment is measured in hours. Illuminate's architecture cannot move at that speed.
AI-native integrations. The unit of work in higher-ed integration is shifting from the hand-authored IDW to the AI-authored agent. The platform that delivers that has to be a new platform — not a bolt-on to a decade-old integration engine.
Helios is our answer. It is not a rewrite of Illuminate. It is a new platform, purpose-built for the standards your institution now has to meet.
One thing to be clear about up front, because it shapes everything below: we are keeping the option to redirect Illuminate to Helios. Section 4 explains exactly what that means and when we would use it.
1 · Accessibility — the bar your procurement office is now enforcing
Why this is decisive
Public higher ed has moved from "prefer a VPAT" to "produce a current VPAT and demonstrate conformance, or come off the approved-vendor list." The DOJ extended the Title II deadline in April 2026, but it extended the date, not the obligation. Software that cannot be audited to WCAG 2.1 AA cannot be procured — even by institutions that would prefer to keep it. This is not a Helios requirement. It is where public-sector procurement is now.
Where Illuminate stands
Illuminate's front end was built before automated accessibility testing was standard practice, and it has no accessibility pipeline in its build: no automated audit dependencies, no end-to-end test harness. That is not a fault of the team who built it. It is the reality of a codebase whose conventions predate today's procurement standards.
Retrofitting VPAT-grade accessibility onto a front end not designed for it is possible and expensive. It means rebuilding the component library, forms, dialogs, tables, keyboard navigation, and focus management — which is to say, replacing the front end anyway.
Where Helios is built
Helios treats accessibility as a build-time gate, not a post-hoc audit.
- Automated accessibility linting and axe-based unit testing are first-class dependencies in the build. A regression fails the build.
- Every public UI change passes a design-review gate before handoff. The rubric encodes WCAG 2.2 AA — visible focus, 4.5:1 contrast, keyboard operability, reduced-motion support, 200% zoom, screen-reader passes. We built to the higher 2.2 AA standard deliberately: Version 2.1 AA is the enforceable bar, and we wanted headroom above it.
- A QA gate drives every interactive control end to end before we ship it. No shipped affordance is a dead button.
- A full unit-test suite plus golden-path end-to-end coverage runs against the deployed environment on every change.
What this means for you. Helios is VPAT-auditable by construction. When your procurement office asks for the current VPAT and evidence of conformance testing, we produce both from the same repository the product ships from.
2 · Security and SOC 2 — hardened by design
Why this is decisive
Higher-ed customers now ask for the SOC 2 report and its bridge letter before renewal, not after. The controls a SOC 2 audit examines — tenant isolation, audit trail, secrets management, least-privilege access, change-management evidence — have to be visible in engineering practice, not just in marketing.
Where Illuminate stands
Illuminate is a seven-service assembly, stitched together over a decade from separate repositories, deployed as Tomcat WARs against MySQL, MongoDB, Redis, ActiveMQ, and a Mule 4 process engine. Its setup runbook is Windows PowerShell-first.
That architecture was sound for the requirements of 2015. It is a poor fit for the requirements of 2026. Change-management evidence has to be assembled by hand from developer documentation rather than produced by the release process. Test and QA reporting runs on a manual per-release cadence. Every control N2N follows on Illuminate follows through effort rather than through design — and effort does not scale in an AI-driven world.
Illuminate is in maintenance. Security-critical patches continue. New feature work does not.
Where Helios is built
Helios was designed against SOC 2 controls as first-class requirements.
- Tenant isolation is architectural. Every table carries a tenant identifier. Every request derives it from verified authentication — never from a header or request body. Postgres row-level security enforces it at the database. This is codified as a repository rule that no code review can waive.
- The audit trail is durable and transactional. Agent lifecycle changes — create, update, deploy, delete — are written to the security audit table inside the same transaction as the change itself, so an audit record cannot be lost when a write succeeds. It is mirrored to platform-wide audit logs. Verified live against the deployed environment.
- Secrets are managed, never in code. AWS Secrets Manager holds SQL and legacy connection credentials. Postgres uses IAM token authentication. No long-lived database passwords sit in application config.
- Per-release evidence is the standard, not the exception. Every release ships with a dated release note: user stories, files changed, unit test plan, QA test plan, DevOps notes, rollback steps. Seventy-eight of them shipped between May and August 2026. That is a documented, auditable release cadence, not a reconstruction.
- Promotion to release is a controlled gate. The August 18, 2026 promotion from development to release is recorded as an auditable event with a per-module diff and a full accounting of features and fixes.
What this means for you. When your CISO or your auditor asks for evidence of change management, tenant isolation, and audit trail on the platform that touches student data, Helios has it. Producing the same evidence for Illuminate means re-engineering Illuminate.
SOC 2 report status: SOC 2 Type II — certified July 21, 2026. Request the report under NDA.
3 · AI-powered integrations — the new unit of work
Why this is decisive
A year ago, "integration" meant a developer hand-authored a workflow. Today the platform does the discovery, the mapping, and the drafting, and a human reviews it. When an institution asks us whether our platform has AI, what they are actually asking is whether their integration backlog can shrink from months to days.
Where Illuminate stands
Illuminate has no LLM-native tooling in its shipping stack. Its process engine is Mule 4, driven by IDWs authored by developers. There is no in-product agent, no natural-language search of the API catalog, no draft-and-review loop, no chat-driven pipeline builder.
Where Helios is built
- Integration Builder Agent. Describe an integration in plain language. The platform searches the 1,900-plus endpoint API Dictionary, drafts the pipeline, wires the field mappings, validates against sample payloads, and hands your developer a draft ready for review.
- AWS Bedrock and Claude, tenant-scoped. Every model call runs through a central client with per-environment model selection, structured audit, cost tracking, and PII redaction. No provider API keys in product code.
- Legacy IDW to Helios agent converter. One flow reads a legacy IDW, drafts the equivalent Helios agent, and produces a fidelity report of what carried across and what did not. We have already batch-converted the most-used legacy IDWs, with evidence captured and tester UAT on the deployed environment.
- Whole-flow migration. Crawl, plan, draft, convert atomically, and report what cannot be carried.
- Service Desk with AI-assisted triage. Issues are filed from an in-product card and carry assignee, comments, attachments, type, and severity. Affected parties are notified automatically.
What this means for you. The platform your team builds integrations on this year is qualitatively different from the one it used last year. Helios is where that difference lives.
4 · What this means for Illuminate customers
We are not asking you to disrupt production. We are asking you to plan a managed migration, with N2N alongside you, on a timeline that respects your academic calendar and your procurement cycle.
- Illuminate remains available to existing customers while your migration is scheduled. Security-critical patches continue.
- Helios is available today to early-access institutions on a QA-promoted release build, cut August 18, 2026. General availability: August 24, 2026.
- N2N drives the migration. The automated converter has already lifted the most-used IDWs into Helios agents in bulk, with a fidelity report for each. What can be auto-converted will be. What cannot, we name explicitly and rebuild together.
- Per-persona training and documentation is standard delivery: CIO, CISO, and IT/Superadmin guides.
- A named migration partner at N2N is assigned to your institution.
- Commercial terms are handled inside your existing agreement. Your named N2N migration partner will walk you through the specifics of scope, timing, and any co-invested work on the planning call — before your team commits any resources.
What we cannot promise
What we are committing to is continuity of function — your integrations keep running. What we cannot commit to is defending a 2015 architecture against a threat it cannot survive.
That is why N2N reserves the right to redirect Illuminate functionality to Helios — a single feature, a single surface, or the platform as a whole — where that is the responsible answer to something outside our control. Specifically:
- a security vulnerability or active threat that cannot be remediated within Illuminate's architecture on a defensible timeline;
- an accessibility, ADA Title II, or procurement requirement that Illuminate's front end cannot be brought to;
- a change in an upstream source system, framework, browser, cloud service, certificate authority, or third-party dependency that Illuminate cannot follow;
- a legal, regulatory, contractual, or audit obligation binding on you or on us.
Where we exercise that right, the redirect is the remedy, not the disruption. Your integrations keep running. The platform underneath them moves. We will give you as much advance notice as the triggering event allows, and where an active exploit allows none, we will act first and document it immediately after.
What we are committing to is continuity of function. We are not committing to defending a 2015 architecture against a threat it cannot survive.
Questions we expect
Is my Illuminate integration in danger of breaking? No. Illuminate will stay available for your existing integrations while your migration plan is agreed and executed, and we commit to keeping your integrations running. What we are not promising is that they keep running on Illuminate forever. If a security, accessibility, or regulatory event forces our hand, we move the surface underneath you to Helios and keep the function intact. See Section 4.
What would actually trigger a redirect? An event we do not control and cannot fix in place: an unpatchable vulnerability, an upstream dependency that breaks Illuminate, a compliance obligation Illuminate cannot meet. Not a business decision to accelerate migration. We are not going to use a security clause as a sales tactic, and you should hold us to that.
How long does an Illuminate → Helios migration take? It depends on the shape and volume of your IDWs. Because the converter is automated and produces a fidelity report, the bulk of well-formed IDWs migrate in hours to days. The complex ones — dense conditional logic, bespoke transforms — are the ones we plan for and rebuild together.
Do we have to rebuild everything? No. That is the point of the converter and the fidelity report. You carry over what carries cleanly, and we co-design a rebuild plan only for the pieces that do not.
What happens to Illuminate? Illuminate is being sunset. We will publish a firm end-of-life date by July 1, 2027, with enough lead time for every customer to complete migration on their own academic calendar.
Why not just add accessibility, better security, and AI to Illuminate? Because that is a rebuild in everything but name — of the front end for ADA Title II, of the dependency and logging substrate for defensible security, and of the integration engine for AI-native workflows. Rebuilding on the old platform ships the same product later, worse, and without the architectural guarantees your auditors and your procurement office now require.
What we are asking of you
- Read this document. Share it with your CIO, CISO, Registrar, and compliance office as appropriate.
- Book a migration-planning call with your N2N contact so we can scope the work against your academic calendar.
- Nominate a technical lead who will co-design the migration plan with our migration partner.
Illuminate did its job for a decade. The standards it was built for no longer exist. We would rather move you now, on your calendar, than be forced to move you later, on someone else's.