Anyone can build a system that always has an answer. The engineering here went into making one that knows when it does not, and says so on the screen instead of generating something plausible.
Every rule below is enforced in code, not in policy, and every number is verifiable in the running product on the Assurance screen.
held_for_review and never auto-actioned.These are not guidelines the model is asked to follow. They are structural properties of the contract every insight must validate against before it is allowed to reach a screen.
Every insight carries a computed confidence: 45% statistical strength, 30% share of the change explained, 25% corroborating signals. Below CONFIDENCE_CUTOFF = 0.6 the insight is marked held_for_review and is never auto-actioned.
You may still commit a held insight. Doing so is permitted, logged, and shown permanently in the Decision Ledger as an override, because a control that can be bypassed silently is not a control.
The why block on every insight carries hypothesis: true as a structural field, not a disclaimer in the copy. It cannot be set to anything else.
Attribution is done by decomposition: contributions are measured shares of an observed delta and sum to 100%. That is arithmetic about what changed, not a claim about what caused it. Closing that gap is a human's job, and the interface says so.
Compliance risk returns null for value at risk. null is an explicitly legal, validated value in the contract. The schema comment reads "some exposures must not be given a price."
A statutory deadline is a legal question. A fabricated fine probability would be the least defensible number in the product, so it declines to produce one and shows the open request count and the days remaining instead.
Every card on every screen is a rendering of a validated insight object. Detection is arithmetic; the language layer only describes what detection already found, and cannot introduce a claim the data does not support.
The raw object is openable from any insight via View insight JSON. If the contract fails validation, the product says contract_valid: false on the Assurance screen and lists the violations rather than hiding them.
No detector knows anything about how the data was produced. Each compares a recent window against your own operation's baseline and raises a card only when the difference clears a stated threshold, which is why a quiet week produces an empty feed rather than invented findings.
| Detector | Must clear | Threshold |
|---|---|---|
| Escalation spike | Two-proportion z-test on escalation rate, per category | z ≥ 2.5 |
| Emerging topic | Volume lift against its own baseline and a share-of-mix z-test | ≥ 1.35× and z ≥ 2.5 |
| SLA risk | Two-proportion z-test on first-response breach rate | z ≥ 2.5 |
| Backlog risk | Sustained queue growth measured as slope over the window | ≥ 3 tickets/day |
| Coaching gap | QA point gap between cohorts and a Welch t-test | ≥ 8 pts and t ≥ 2.5 |
| NPS drop | Fall in Net Promoter Score against baseline | ≥ 8 points |
| CSAT drop | Fall in mean star rating and a Welch t-test | ≥ 0.25 stars and t ≥ 2 |
| Churn risk | Repeat escalations plus detractor NPS or low CSAT, above an ARR floor | ≥ $60k ARR, ≥ 5 accounts |
| Compliance risk | Open statutory data requests against their legal deadline | deadline-driven |
A global minimum sample of 40 recent records applies before any anomaly is raised, regardless of how extreme the signal looks. Thresholds are declared in one file, config/thresholds.js, rather than buried at their call sites, specifically so a reviewer can disagree with them in one place. That file separates the four business dials a customer owns (what counts as low adoption, how far ahead a renewal matters, what size of usage fall is a decline, how long silence lasts before it means something) from the statistical bars above, which exist to hold the false-positive rate down and are ours to defend rather than yours to turn. Two customers do not share a definition of "low adoption"; they do share a definition of significance.
A capability list tells you what a vendor wants to be judged on. This is the other list, and for a system that produces decisions, it is the more informative one.
Compliance risk is reported as open requests and days to statutory deadline. It is never converted into a dollar figure, and it is deliberately excluded from the total revenue-at-risk rollup.
Ask the Executive Copilot something the engine has not computed and it says so, then lists what it can answer. It does not generate a plausible response to fill the silence.
Value at stake is always a range, and the widest source of uncertainty is named explicitly: the conversion band is a stated assumption, not a measurement, and the product says which is which.
The Decision Ledger snapshots severity, confidence and the metric at the moment of commitment. Later engine passes cannot back-date them, so a decision that turned out badly stays visibly bad.
If insight validation fails, Assurance reports contract_valid: FAIL and prints every violation. The failure is surfaced rather than swallowed.
Marked honestly, because a trust page that overstates its own controls defeats its purpose. Live means it works in the product you can open right now. Planned means it is designed and scheduled, and nothing more than that.
| Control | Status | Detail |
|---|---|---|
| Client-side processing | Live | The MVP runs entirely in your browser. No operational data is transmitted to a server, and an uploaded CSV never leaves the tab. |
| Insight contract validation | Live | Every insight is validated on every engine pass; the pass/fail result and any violations are shown on the Assurance screen. |
| Decision audit trail | Live | Commitments are recorded with the evidence snapshot, the owner role, the playbook id, and every lifecycle transition with its timestamp. |
| Provenance tracing | Live | Each published field records the source column or derivation it came from; the full trace is listed on Assurance. |
| SSO via OIDC / SAML | Planned | Phase 4. Required for the Govern tier at general availability. |
| Role-based access control | Planned | Phase 4. Read-only viewer, decision-maker and auditor roles, with viewers unlimited on every plan. |
| SOC 2 Type II | Planned | Not certified. Audit is scheduled to begin after the production pilot. We will not imply otherwise on a trust page. |
| Data residency & private deployment | Planned | Enterprise tier. Regional pinning and single-tenant deployment. |
| Encryption at rest and in transit | Planned | Applies from the first server-side deployment; the current build has no server-side store to encrypt. |
OpsPulse is a functional MVP, not a generally available product. The engine, the detectors, the thresholds, the contract validation, the provenance tracing and the decision ledger are all real and running in your browser. You can open the JSON behind any card and check the arithmetic.
The dataset is simulated. The enterprise controls marked Planned above are designed and scheduled but not built. We are stating that plainly here for the same reason the engine refuses to price a compliance exposure: the moment a trust page starts rounding up, it stops being useful to the person reading it.
Open the live platform, go to the Assurance screen, and check the detector thresholds, the held-for-review count, the provenance trace and the contract validation result against everything stated here. Then commit a decision and watch the ledger tell you what happened to it.