Case Study — Government Data Platform
When data engineers configure access control on classified records, they make permanent decisions. Most of them don't fully understand that — until it's too late. My job was to make sure they did.
The Problem
Koverse is a data platform for ingesting, managing, and analyzing large datasets in secure government environments. Its most technically significant feature is ABAC — Attribute-Based Access Control — a security mechanism that determines who can see what data based on matching attributes between records and users.
Configuring ABAC correctly at the moment of ingest is critical. Getting it wrong doesn't just cause access issues — it can result in classified data being exposed to users who shouldn't see it, or locked away from analysts who need it. And once the data is imported, the ABAC labels can never be changed.
"The design question: how to make a permanently consequential decision feel weighty without making the product feel hostile."
Koverse also has an edge extension — a platform for managing data across distributed, geographically dispersed deployments. Think: a network of military field sites, each running local data infrastructure, all feeding back to a central node. Two different products, one shared design philosophy: the interface is responsible for making the consequences of decisions visible, especially when those consequences are severe and irreversible.
Key Screen — Access Control Config
The Data Layer
Koverse handles both structured tabular records and unstructured documents — images, PDFs, raw files — within the same dataset container. The mixed dataset view had to present both data types coherently, without forcing users into a mode-switched interface that felt like two separate products.
Each record renders its file thumbnail alongside its raw metadata — body text, document ID, record type, file storage flags. The SQL/Lucene search bar and the JSON view toggle give power users the control they need without cluttering the default view for analysts who just need to see what's there.
Key Screen — Most Operationally Specific
The Site Manager
At the site level, the design problem shifts from geographic overview to operational monitoring. The operator needs to know: is this site healthy? Is data flowing correctly? I organized the site manager around status states rather than data structures.
Published, Connected, Available — these states map to operator actions, not technical conditions. An operator who sees "Available" when they expect "Published" knows exactly what to investigate without understanding the underlying data architecture. The throughput metrics (80 GB/s, 307.8 upload speed) are displayed in real time because in an edge environment, a site showing 0 GB/s when it should be showing 80 is a site that may be offline, disconnected, or under active disruption.
Takeaways