DAFFA ZAHY KHAIRY
Data reliability / prototype

SignalOps

Every number carries its trust state, its source run and its definition.

Supporting projectData quality & reconciliationSynthetic dataNot deployed
Role
Solo — from my written product spec (SIG-PRD-001); built with AI coding agents under my direction
Stack
FastAPI, PostgreSQL, Celery + Redis, S3-compatible storage, Keycloak (OIDC), Next.js, OpenTelemetry
Timeline
November 2026
Status
Built · tested locally · not deployed · no public repo
Operations overview labelled Synthetic demo data: workspace trust marked Blocked, 104 active incidents of which 65 critical, and KPI tiles such as Activation Rate 100 percent marked Blocked and Completed Orders 2,445 marked Stale
After the test run the workspace is Blocked, so no KPI shows as verified.Supporting project
83backend tests passing
21frontend unit tests passing
12 / 12browser journeys passed
THE PROBLEM

A dashboard that is wrong looks the same as one that is right.

In a telecom-style business, a broken payments schema or a batch sent twice quietly makes revenue wrong. The dashboard does not say so.

SignalOps treats trust as a state the data has to earn: detect → validate → investigate → resolve → verify → publish.

WHAT WAS BUILT

Four rules the data has to pass.

CSV or REST source → raw evidence → validation → reconciliation → publication gate.

  1. 01

    Keep the raw file, then check it

    Each batch is stored with its SHA-256 before parsing. Invalid rows are quarantined with a reason, never trusted or silently corrected.

  2. 02

    A replay cannot move a KPI

    Idempotency keys and unique source IDs make a resent batch add nothing; a changed event needs a higher version or is rejected.

  3. 03

    Blocked is not zero

    A failed critical check stops the new snapshot and keeps the last good one. KPIs read Verified, Warning, Stale, Blocked, Processing or Unavailable — never 0 for missing data.

  4. 04

    Close incidents on evidence

    Closing needs a reason plus a passing check from a run published after the failure. A note is not enough.

THE CONSOLE

Sources, metrics, incidents.

Keycloak sign-in, server-side role and tenant checks on every request, and background workers for ingestion and exports.

Data sources and ingestion: connected CSV sources with connection health and trust states, including a source called Bad schema marked Degraded and Blocked
Sources: a broken-schema file is Blocked; others keep their state.
Metric explorer: governed metric dictionary with Activation Rate, Completed Orders, Net Revenue and Successful Payments, each with a trust state, an owner, an as-of time and a 15-minute SLA
Metrics: versioned definitions, owners, trust states; no free-form SQL.
Incident queue with filters by status and severity and a list of open high-severity freshness incidents
Incidents: full of browser-test fixtures, not real alerts.
EVIDENCE & LIMITS

Tested on one laptop. Not production.

CheckResult
Backend: unit, integration, API contract83 passing · 13 Nov 2026
Frontend unit tests21 passing · 13 Nov 2026
Browser journeys, sign-in to incident close12 / 12 · 11 Nov 2026
Encrypted backup and restore drillRound trip passed locally
  • Not yet: a deployment, a load test (200 users and 10 million rows are spec targets, not results), TLS, managed secrets, external alert routing, or a full accessibility audit.
  • Some integration tests stub storage and the message broker; a worker crash under load is untested.
  • Built with AI coding agents under my direction; the repository is not public yet.
Journey and drill detail

Backend tests include PostgreSQL integration tests. The 12 journeys: sign-in, CSV and REST ingestion, the publication gate, tenancy, offline behaviour, and detect-to-close for an incident. The encrypted backup and restore drill covers the database, identity and files.

Fictional business and synthetic data; no user, client, deployment or business result is claimed.
DAFFA ZAHY KHAIRYPrototypes on synthetic data · © 2026