What it does
An operator registers a model artefact by its storage location (S3 or GCS), maps its declared inputs to feature views already produced by Conduit, and configures where its predictions should be written back to. Augur validates that mapping before anything runs — a model input with no matching feature is rejected at save time, not discovered mid-execution.
Once a Prediction Workflow is enabled, Augur runs it on a Conduit webhook, a cron schedule, or on demand: it fetches the right feature vectors per entity, executes the model, and writes each prediction back through Conduit’s API alongside a SHAP-based explainability record. Every run is tracked as an immutable record — status, entity count, duration, and the feature importances that drove the result.
Where it fits
Conduit turns raw CDRs into features. Augur turns those features into predictions. The boundary is strict: a registered model has no dependency on Conduit or the underlying feature store, and Augur never touches raw network data directly — all feature I/O is mediated by Conduit’s API. That separation is what lets one registered model serve multiple prediction workflows, and what keeps every prediction traceable back to the exact feature set and model version that produced it.
Explainability as a first-class output
Every prediction Augur produces ships with a feature importance vector and a confidence score, not just a number. That is not a reporting add-on — it is the audit trail GDPR Article 22, the EU AI Act, and Brazil’s LGPD Article 20 require whenever a scoring model informs a commercial decision like a churn-triggered offer or a service restriction. Run records, model versions, and per-entity explainability are retained so an operator can answer “why did the model decide this” without digging through logs.