How we keep the house honest.

01 · Foundations

Every foundation model in the inference path is Apache 2.0 or MIT. The Llama family is prohibited because the license forbids using model outputs to train non-Llama models — adopting Llama anywhere in the path would taint any future FinAi-from-scratch model. Claude, GPT and Gemini are forbidden for the same downstream-training reason plus the data-residency one (those vendors process inference outside our VPC).

The current approved foundation families are Qwen (Apache 2.0), DeepSeek (MIT), IndicBERTv2 (Apache 2.0), Sarvam-1 (Apache 2.0), XLM-R (MIT), BGE (MIT) and Whisper (MIT). A boot-time check rejects prohibited foundation-model families before the application starts. License compliance is enforced automatically at ingest and at boot.

Caveat — sentiment_analyzer. One distilled adapter (the legacy sentiment classifier) carries a tainted-derivative weight and is shipping under a public replacement plan. See /models/sentiment_analyzer.

02 · DPDP §12 erasure

When a Data Principal exercises erasure, an automated worker deletes or anonymises every linked record — identity, financial history, model-call audit, KYC artefacts, derived memory and notification queues — across primary stores and object storage. The dependency-ordered cascade is verified by an internal test and is not enumerated publicly.

Each cascade is HMAC-signed onto the audit chain (§3 below), so erasure itself is verifiable. The grace period and worker cadence are documented in /privacy.

03 · Audit chain

The audit log is tamper-evident by topology: each row binds the prior row's HMAC, so a single edited byte breaks the chain at verification. The topology is HMAC chain — not a Merkle tree. That is a deliberate choice: chain verification is O(n) sequential, which trades random-access proof speed for a simpler operator surface (one HMAC per row, no tree-rebuild on insert).

Chain verification runs as an internal operator job and exits non-zero on any break. The HMAC key is held in HashiCorp Vault and rotated on a schedule that operator-runbook teams control independently of the application.

04 · Drift

The Observatory runs six drift-detection strategies across 27 of the 33 registered models: tabular (PSI + KS), RL (reward-mean drop + variance), vision (embedding PCA PSI + confidence PSI), text classifier, binary imbalanced (score-distribution KS + capture-rate divergence, designed for high-skew classifiers like the Scribe signal classifier where the skip rate exceeds 90%), and forecast residual (coverage / quantile p10/p50/p90-vs-actual, for the TimesFM forecasters).

The policy engine applies a 2-consecutive-check rule before a drift signal escalates — single-window noise is tolerated. Every monitored model is listed at /models, and each card cites its strategy. There are 36 public model cards on the landing today.

05 · Self-healing

When a drift signal escalates, the Observatory generates a candidate proposal (best-effort B → A → no-candidate fallback) and writes it to the proposals queue. A proposal moves through four states: proposed → approved → executed / rejected / expired.

The approve-and-execute step requires a fresh TOTP code from either the CTO or the CEO. A six-hour cool-down kicks in after a rollback so the same candidate cannot churn the queue. The full process is documented in our internal operator runbooks.

06 · Synthetic data

Synthetic data generators write a hash manifest alongside every corpus. The manifest records the generator slug, the seed, the row count, the schema version, and a SHA-256 of the resulting parquet. Trainers that consume a corpus verify the hash before fitting; a mismatch aborts the run.

A boot-time check rejects prohibited foundation-model families before the application starts. License compliance is enforced automatically at ingest and at boot — any foundation-derived synthetic data from a prohibited family is rejected at the corpus-manifest step, before a single row reaches the trainer.

07 · Crisis response

Mukodi's safety stack is not a wall — it is a soft routing layer. When the distress, debt-spiral or financial-abuse guardrail fires in a user's session, the response chain steps the user out of the AI loop and surfaces a contact list for live human help.

The helplines surfaced (India) are:

• iCall — 9152987821 (TISS-run psychosocial helpline; Mon–Sat 08:00–22:00 IST).last-verified: 2026-05-14 · source: icallhelpline.org
• Vandrevala Foundation — 1860-2662-345 / 1800-2333-330 (24×7 mental-health helpline).last-verified: 2026-05-14 · source: vandrevalafoundation.com
• AASRA — +91 9820466726 (24×7 suicide-prevention helpline).last-verified: 2026-05-14 · source: aasra.info
• 112 — pan-India emergency response (police / fire / medical / disaster).last-verified: 2026-05-14 · source: mha.gov.in

The crisis-response and breach runbooks are maintained internally and exercised at each quarterly DR drill. Helplines are listed for India because that is the only jurisdiction Mukodi operates in today. Adding a new country requires the same triage panel.

08 · Vendor DPA registry

Mukodi runs primarily on its own VPC. The current sub-processor register lists infrastructure providers only (AWS for compute and S3; Cloudflare for CDN edge; Sentry for error capture). No third-party LLM vendor processes user data — inference is served from our own vLLM cluster, and the openai Python SDK we use talks to that cluster on the OpenAI-compatible protocol (it does not talk to api.openai.com).

A formal Vendor DPA Registry — one row per sub-processor with contract date, scope, region, and DPDP-§8 transfer basis — is maintained by the operator and reviewed at every quarterly DR drill. The DPO publishes the registry on request via the contact in §9 below.

09 · Contact

For any DPDP §13 grievance, data-subject request, or security disclosure, write to the addresses below. Mukodi acknowledges DPDP requests within the prescribed window; a more detailed flow is documented in /privacy.

Data Protection Officer

[email protected]

DPDP §12 erasure, §13 grievance, automated-decision review.

Security disclosure

[email protected]

Vulnerability reports, abuse, suspected breach. Coordinated disclosure preferred; operator acknowledges within 72h.

Legal inbox

[email protected]

Operated by Nilfee Fintech Private Limited, Chennai.

Press

[email protected]

Fact sheet, brand kit, statements — see also /press.

DPDP §9 imposes a strict default-deny posture on Data Principals who are minors (under 18 in India). Mukodi implements this as a platform-wide short-circuit in the consent layer.

When a user is identified as a minor:

• All four consent flags default to False, irrespective of any UI state.
• No PII is processed in any AI inference path; the capture pipeline short-circuits before any model call.
• No memory capture is written to any store.
• No ad personalization or correlation. The minor branch is fail-closed.
• A boot-time invariant enforces that no minor-inferred field reaches a credit-risk feature.

The minor short-circuit is not a UX feature — it is a DPDP §9 obligation, and it is locked by boot guard. Removing or weakening it would fail boot and roll the deploy back.

Mukodi's credit-risk surface — the credit_risk_scorer and the loan_default_predictor — informs consequential lending decisions. Under the DPDP §11 access right, a Data Principal can ask what personal data informed a decision about them — and we go further: every borrower is entitled to a plain-language explanation of any automated decision that affects them. We meet that obligation in two layers.

Layer 1 — SHAP attributions. Every score is accompanied by SHAP feature attributions exposed on the operator-facing surface. Partner lenders receive the SHAP values via the B2B API and are contractually required to translate them into plain language before showing the borrower.

Layer 2 — disparate-impact metrics. Both models publish disparate-impact metrics across protected attributes (gender, region) on their respective model cards. The metrics are recomputed on every retrain and the model card's “limitations” section documents the current observed gap. A persistent gap outside the acceptance band is a deploy gate — the self-healing observatory will not promote a candidate model that worsens the gap.

Partner-lender independent validation. Every partner lender integrating the credit-risk API signs a rider committing to their own disparate-impact validation on their book. The rider is reviewed by the Mukodi compliance officer before the API key is provisioned. The rider language is published on /partners and reproduced verbatim in every partner DPA.

A borrower whose loan was declined and who wants a plain-language explanation should write to [email protected] under DPDP §13 grievance. The DPO will produce the SHAP-derived explanation in writing within the §13 grievance window.