Where your data lives
Where the systems we build run, what that means for the data they hold, and what changes once those records are personal.
Where systems run
We hand back a system that does that first pass inside your environment, validated against your own historical data and deployed into the workflow your team already uses.
Constraints that rule an approach out
Data residency, an air-gapped environment, a regulator's expectations.
When a system holds personal information
Once the analytics carry live borrower records — names, employers, salaries, credit scores, loan terms — the dashboards stop being a convenience and become a system holding non-public personal information, with the obligations that follow.
That was the mortgage engagement. What it meant in practice:
- Served over TLS behind authentication, not opened from a local folder.
- Role-scoped server-side: a loan officer sees their own pipeline, a principal sees the full book, and the endpoint enforces it rather than trusting the client — anything the browser receives is available to whoever holds the browser.
- Applicant-identifying fields are omitted entirely from aggregate views that don't need them, so charts and distributions are served from records carrying no borrower identity; identity is returned only for the record-level table and only to entitled roles.
- Access logged with requesting user, scope returned, and timestamp — which is what makes it possible to answer who saw what, if that's ever asked.
- Replica credentials live in service configuration and never reach the browser; the dashboards hold no connection and no query capability, so the origination database's attack surface is unchanged by the addition of analytics.
How we talk about clients
Most of them cannot be named, and the same discretion applies to yours. The reasoning is under who we are.