Architecture
Heronix products share the same architectural commitments: run on district infrastructure, sell under a perpetual license, and tokenize student PII before it ever crosses the network perimeter. This page is about how the software is built — not a product you buy.
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. Support and updates are a separate, optional agreement — never a gate that locks the software itself.
What this means in practice: no per-student-per-year pricing that scales against enrollment growth. No renewal cliffs.
Guardian by default
Every Heronix product tokenizes student PII before any data leaves the network boundary. Each external integration receives unique, per-vendor tokens. The raw student record never leaves the district in the clear. This is not an add-on module — it's how the product is built.
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 any external integration needs data, Guardian issues a per-vendor token that references that student — but the token itself cannot be reversed back to the student's identity without access to the master key, which never leaves the district.
Every integration gets unique tokens. A breach at one vendor exposes only that vendor's token space. Other vendors are 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.
Is Guardian a product SKU I can order?
No. Guardian is the privacy architecture built into every Heronix product. You don't buy it separately — it's how PassTrack, Suite, and every future Heronix tool handle student data by default.
So Guardian isn't optional?
Correct. There is no "turn off Guardian" configuration. Tokenization is how data flows. If a Heronix product needs to talk to an outside system, it does so through tokens.
Does this mean the product runs slower?
Tokenization happens 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 logs 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