Case study · Privacy and compliance visibility platform
ArgusEdge
Privacy and compliance visibility platform for GDPR.
- Industry
- Privacy, compliance and regulated operations
- Current status
- Live — In production
- Focus areas
- Compliance & Privacy, Internal Business Systems, AI Platforms
- External links
- Not yet public
01 · Executive summary
In brief
ArgusEdge gives organisations a current view of their GDPR position instead of a periodic one. Processing activity is evaluated continuously against defined rules, each compliance exception is raised with a severity and a named owner, and every action taken against it is recorded in an append-only log an examiner can read.
02 · Business context
The business and its environment
The organisation held its GDPR position in documents: a records-of-processing spreadsheet, a policy set and a quarterly report. Between reports, nobody could say with confidence which processing activities were outside policy or who was resolving them.
03 · The challenge
The problem that existed
Compliance exposure depended on individual knowledge and periodic manual reporting. Exceptions were found late, ownership was ambiguous, and there was no defensible record of how an issue had been handled.
04 · Product vision
Why the product was created
The product exists because a compliance position that is only true on reporting day is not a position. Making exposure continuous, owned and evidenced was the business decision; detection sophistication was explicitly not the priority.
05 · Solution
The platform and the approach
A monitoring and review layer over existing operational and data systems. Rules evaluate processing activity continuously, exceptions are raised with severity and a named owner, and every action taken against them is recorded immutably.
06 · Architecture overview
Structural decisions
The decisions that were expensive to change later, and were therefore made first.
- Ingestion layer normalising records from multiple upstream operational systems
- Rule evaluation service producing exceptions with severity and routing metadata
- Ownership and escalation model with time-bound service levels
- Append-only audit log; review actions are recorded, never overwritten
- Reporting views separated from transactional data to keep dashboards cheap
Architecture diagram to follow
07 · Key features
What the platform actually does
Listed as capabilities that change how work happens, not as a feature inventory.
Continuous rule evaluation
Incoming operational activity is evaluated as it arrives, so exceptions surface in hours rather than at month end.
Named ownership
Every exception is routed to a person, not a team inbox, with a time-bound service level attached.
Escalation by service level
Exceptions escalate automatically when the service level lapses, which removes the need for chasing.
Append-only audit history
Actions are recorded and never overwritten, so the handling of any exception can be reconstructed exactly.
Severity-weighted queue
Reviewers see the highest-consequence exceptions first, rather than the most recent.
Management reporting
Reporting views are separated from transactional data, so dashboards stay fast and cheap as volume grows.
08 · Technology stack
What it runs on
Conventional choices, selected so a team other than the one that built it can run and extend it.
- Application
- TypeScript
- React
- Server-side rendering
- Data
- PostgreSQL
- Append-only audit tables
- Scheduled jobs
- Platform
- Managed Postgres and auth
- Edge delivery
- Security
- Role-based access control
- Structured access logging
09 · AI usage
Where AI adds value, and where it does not
Narrative summarisation of exception clusters for management reporting. Detection itself is deterministic and rule-based by design, so that every exception can be explained and reproduced.
10 · Security and compliance
What was decided before the build
Included because these decisions are difficult and expensive to retrofit.
- Role-based access control with segregation between reviewers, owners and administrators
- Append-only audit log designed for external examination from the first release
- Structured access logging, so who saw what is answerable
- Deterministic detection logic, so every exception can be explained and reproduced for an auditor
11 · Current status
Where it stands today
Live
In production use. Exception detection moved from a monthly cycle to continuous, and each exception now carries an owner, a service level and a reviewable history.
12 · Lessons learned
What the work taught
Strategic rather than technical: the judgements that carry into the next engagement.
- Detection logic that cannot be explained to an auditor will not be trusted, regardless of accuracy.
- Ownership and escalation matter more to outcomes than detection sophistication.
- An append-only audit model is far cheaper to design in at the start than to introduce later.
Interface
Product views
Reserved for published screenshots. Alt text and captions are in place so the section is meaningful once images are added.
Image to follow
Image to follow
15 · Next evolution
What comes next, and why
Sequenced against business value rather than technical interest.
- Rule authoring for operational leads, with review and versioning, so change does not require engineering
- Predictive prioritisation of exception clusters, kept advisory and separate from detection
- Deeper upstream connectors to shorten the path from source system to exception
The best products begin with the right questions.
Send the business context and the constraint you are working against. I will reply with a direct read on the approach I would take, and whether I am the right person for it.