Architecture
Heronix products share the same architectural commitments: run on district infrastructure, sell under a perpetual license, and route external integrations through Guardian, a dedicated gateway that tokenizes student PII before it crosses the network perimeter. This page is about how the software is built.
Status: Guardian is a dedicated gateway application that deploys alongside Heronix products and fronts their external integrations. It is functional and in internal testing; per-vendor integrations are pending production validation. PassTrack keeps student data on district servers and ships without external vendor integrations, so PassTrack pilot deployments do not include the Guardian gateway.
Three architectural commitments
Not marketing positions, constraints Heronix products are built under
On-premise
Products run inside the district's own network. No required cloud connectivity for core operation. Offline-first where it makes sense, kiosks, classroom tools, and attendance capture function without an internet connection and sync when reachable.
What this means in practice: no external dependency can take a district's system offline. No vendor can revoke access by disabling your account.
Perpetual license
Districts buy the software, not a subscription to access it. One license. The district keeps running the software as long as it wants to, on hardware it controls. Updates, security patches, and support are provided under the annual upkeep agreement that accompanies every license.
What this means in practice: no per-student-per-year pricing that scales against enrollment growth. No renewal cliffs.
Guardian at the boundary
External integrations route through Guardian, a dedicated gateway application that tokenizes student PII before data leaves the network boundary. Each external integration is designed to receive a unique, per-vendor token namespace, so the raw student record does not leave the district in the clear.
What this means in practice: a breach at any single vendor cannot reassemble a district's roster.
How Guardian tokenization works
Student PII never leaves your network in the clear
One master record. Per-vendor tokens.
Inside the district, each student has a single master record stored in the Heronix database. When an external integration needs data, Guardian is designed to issue a per-vendor token that references that student, the token cannot be reversed back to the student's identity without access to the master key, which is designed to never leave the district.
Every integration receives unique tokens. A breach at one vendor would expose only that vendor's token space. Other vendors remain unaffected. The underlying student identities are not at risk from any single external breach.
Tokenization at the perimeter
Tokens are generated at the edge of the district network. Data leaves tokenized, never in the clear.
Per-vendor isolation
Each vendor integration gets its own token namespace, no cross-vendor correlation possible.
Minimum data by default
Integrations receive only the fields they need, a grade, not the full record.
Per-vendor token example
TKN_ABC123DEF456
VNDA_7H4K9D2X
VNDB_3M8P5K1Q
VNDC_6N2H9L4X
If Vendor A is breached:
Only VNDA_* tokens are exposed. Vendors B and C are unaffected. Real student identities are never reconstructable from any single vendor's data.
Is Guardian something I buy?
No. Here's the clarification.
Do I order Guardian separately?
No. Guardian is a dedicated gateway application that deploys inside your network as part of a Heronix installation. It isn't priced or sold on its own, it ships alongside products that integrate with outside systems and fronts those integrations. Products with no external vendor integrations, such as PassTrack, run without it.
So Guardian isn't optional?
For any Heronix product that talks to an outside system, correct. There is no supported configuration that sends student PII to an external vendor in the clear, integration traffic routes through Guardian and leaves tokenized.
Does this mean the product runs slower?
Tokenization is designed to happen at the integration boundary, not on every internal query. Internal operations use the master record directly. Only data leaving the district is tokenized.
Can I audit who saw which data?
Yes. Guardian is designed to log which external integration received which fields, for which students (by token), and when. Auditable locally, logs stay on your servers.
Want the technical detail?
We'll walk IT and security teams through the tokenization boundary, the master-key handling, and how Guardian interacts with state-reporting integrations. Bring your most adversarial threat model.
IT & Security overview Request a technical call