Data Science & Machine Learning
We turn the audit log into decisions — anomaly signals, health scores, reconciliation analytics and the dashboards that tell an operations lead whether the platform is healthy. Our models are explainable by requirement, not by accident, and our predictions are auditable because any operator may ask why. A black box on an alert path is a liability we cannot defend, so we do not ship one.
Models in production
Models with explainability artifacts
Inference p99 on the fraud path
Fraud recall on the holdout set
Why Data Science
The audit log, read forward
Every event that touches a FiduciaWay platform writes to an append-only, cryptographically chained audit log. That log is not just a compliance artifact; it is the training data our models read from, and the ground truth any auditor will hold us to. We engineer accordingly: features are derived from the audit log, not from a separate analytics store that can drift from reality; models are explainable by construction, with SHAP attributions attached to every prediction; inference is served behind the same SLO envelope as a platform API, because an anomaly signal that times out is an anomaly signal that missed. The audit log is the past; our work is to read it forward, into a decision an operations lead can defend in front of any reviewer.
We refuse the superstition that a deep neural network is always the answer. On an alert path, an explainable gradient-boosted model that an operator can interrogate beats a marginally-more-accurate black box we cannot defend. Our features are versioned, our training runs are reproducible, our holdout sets are immutable, and our model risk review is a real gate, not a rubber stamp. We test for bias on the populations our model scores, we monitor for drift in production, and we can roll a model back to its previous version within minutes if its behaviour changes. The dashboard is a convenience; the audit log is the contract. And because our predictions gate real operations, we treat a false positive as carefully as a false negative — a held job is a customer's workflow, not just a metric.
What we build
From fraud signals to compliance dashboards, here is what leaves our keyboards and ships to production.
Fraud Detection
Real-time anomaly scoring on every service and pipeline, with SHAP attributions attached to every prediction so an analyst can see why a job was flagged. Inference p99 under 200ms, on the alert path.
Risk Scoring
Explainable health scores on services, pipelines and integrations — calibrated against a holdout set that is immutable once a model is in production.
Reconciliation Analytics
Source-vs-bus-vs-target reconciliation runs hourly; analytics flag the discrepancy patterns a human should investigate, so the on-call engineer is paged for causes, not symptoms.
Compliance Dashboards
Live dashboards that tell a compliance officer whether the platform is healthy — by SLO, by error budget, by regulatory metric — with drill-down to the audit log on any anomaly.
Regulatory Reporting
Automated regulatory reports generated from the audit log, reproducible on demand, signed and timestamped. A regulator can ask "why" and the answer comes from data we already have.
ML Platform
Versioned features, reproducible training, immutable holdouts, model risk review and drift monitoring — the boring infrastructure that lets a data scientist ship a model safely.
How we work
Our loop is audit-log-first, explainable by construction. Here is one orbit, from question to canary.
Frame the question
We frame the decision the model has to support — "should we hold this job?" — not the accuracy it has to hit. A model that answers the wrong question at 99% is worse than a model that answers the right one at 90%.
Build features from the audit log
Features are derived from the audit log, versioned, and reproducible. A feature that cannot be recomputed from the log does not ship, because the regulator may ask us to.
Train with explainability
Models are explainable by construction; SHAP attributions are attached to every prediction during training, so the analyst can interrogate any decision the model makes.
Validate on an immutable holdout
The holdout set is immutable once a model is in production; we test for bias on the populations the model scores, and we monitor for drift in production against this baseline.
Deploy behind a flag
A new model ships behind a flag at 1%, shadow-scored against the incumbent; we compare decisions, not just metrics. Drift beyond the threshold reverts within minutes.
Monitor drift, ship a fix
Production drift is monitored against the holdout baseline; a model that drifts reverts to its previous version automatically, and a retrain is queued — not a fire drill.
Definition of done
A model ships only when all of this is true
Explainable
SHAP attributions attached to every prediction; an analyst can interrogate any decision the model makes.
Reproducible
Training runs reproducible; features versioned and recomputable from the audit log; the model can be rebuilt on demand.
Drift-monitored
Production drift monitored against the immutable holdout baseline; a model that drifts reverts to its previous version automatically.
Bias-tested
Tested for bias on the populations the model scores; a model that scores a protected group differently without justification does not ship.
Auditable
Every prediction is logged with its inputs, its SHAP attributions and its model version; a regulator can ask "why" and the answer comes from data we already have.
Tools & why we use them
Boring on purpose. Each tool was chosen for its failure mode, not its demo.
The lingua franca of data science; we keep the type discipline and the test coverage an ML codebase usually lacks.
Explainable gradient-boosted trees beat a marginally-more-accurate black box on an alert path an operator can interrogate.
Attributions attached to every prediction, so an analyst can see why a job was flagged. A black box we cannot defend does not ship.
Versioned feature store derived from the audit log, never from a separate store that can drift from reality.
Reproducible training runs, immutable holdouts, model versioning — the boring infrastructure that lets a data scientist ship a model safely.
Reproducible analytics directly over the audit log; a regulator can ask "why" and the answer comes from a query we already have.
Features computed from the audit log stream, in real time; a fraud signal that times out is a fraud signal that missed.
Compliance dashboards that drill down to the audit log on any anomaly; the dashboard is a convenience, the log is the contract.
How we interface
Where data science meets the rest of the company
Backend
Data exports are events off the audit log, never direct DB taps. Analytics never pins the write buffer; risk models see the same events the regulator will.
DevOps
DevOps owns the Kafka topic that feeds the analytics warehouse and the canary on a new model. A model that drifts reverts within minutes; we own the drift detector, they own the rollback lever.
QA
Bias and drift tests run on every release candidate; QA owns the bias-test matrix that runs against every model before it ships to a critical path.
Compliance
Compliance owns the questions; we own the answers. A regulator's "why" is a query we already have, against an audit log we already trust — reproducible on demand, signed and timestamped.
Questions we get asked
Why explainable models only?
An operator will ask "why did you flag this job?" and an answer of "the model said so" is not an answer. SHAP attributions attached to every prediction let an analyst interrogate any decision; a black box we cannot defend in front of an operator does not ship, even if it is more accurate.
How do you detect model drift?
Production predictions are scored against an immutable holdout baseline; drift beyond a threshold reverts the model to its previous version automatically, and queues a retrain — not a fire drill.
What is model risk review?
A real gate, not a rubber stamp: bias tested on the populations the model scores, drift monitored, holdout immutable, rollback tested. A model that fails any of these does not ship to a critical path.
How do you protect customer PII?
PII stays in the audit log, access-listed and encrypted; the feature store holds only derived, minimised features. A leak from the feature store cannot expose a customer's identity.
How fast is inference on the alert path?
p99 under 200ms, served behind the same SLO envelope as a platform API. An anomaly signal that times out is an anomaly signal that missed, so we treat inference latency like product latency.
Our mission
Turn the audit log into decisions an operations lead can defend in front of any reviewer. Our models are explainable by requirement, our predictions are auditable, and our features are recomputable from the log. The audit log is the past; our work is to read it forward — into a decision, a defence, and a dashboard we can stand behind.