# UdyamLinc — Technical Architecture

Team LincFusion · LincPay Solutions Pvt. Ltd. · NABARD Hackathon

This document is the build contract for `UdyamLinc-Backend`. It records what the
system is, what is built, and what is deliberately deferred.

---

## 1. Shape of the system

```
                    Enterprise PWA / Field Officer Console
                                     │
                                     ▼
                       Spring Boot application (one deployable)
                                     │
   ┌──────────────┬──────────────────┼──────────────────┬──────────────┐
   ▼              ▼                  ▼                  ▼              ▼
enterprise   institutional       ingestion            rules           ai
(ledger)     (CBS, DPD, UPI)   (mandi, climate)    (trip-wires)   (LightGBM)
   │              │                  │                  │              │
   └──────────────┴────────┬─────────┴──────────────────┴──────────────┘
                           ▼
                    feature store  (tall = truth, wide = read)
                           │
                           ▼
                      risk engine  (rule-based now, model later)
                           │
                           ▼
              alerts · dashboard · reports · officer playbook
```

### One deployable, not seven services

The module boundaries above are **Java packages, not microservices**. At pilot
scale — four districts, 142 enterprises — separate deployables would buy
distributed transactions, cross-service auth and five release pipelines in
exchange for nothing. The package boundaries are enforced by convention (no
cross-package entity imports; talk to a neighbouring module through its service),
so `ingestion` or `ai` can be lifted out later when volume actually justifies it.

For the same reason there is no separate API gateway component: at this scale the
application *is* the gateway.

---

## 2. Three principles that decide whether this survives real data

### 2.1 External feeds are never called in the request path

Mandi prices, egg rates and climate series are pulled by a scheduled job at
02:00, validated, and written to `market_signal` / `climate_signal`. Scoring and
login read those tables and nothing else. A government endpoint being down
degrades tomorrow's freshness; it never fails a user request.

### 2.2 The feature store is the only interface to the model

Ingestion writes signals. Feature engineering turns signals into indicators. The
AI layer consumes **only** engineered features. This is what allows the model to
be retrained or replaced without touching ingestion, storage or the API.

The store has two shapes:

| Table | Shape | Purpose |
|---|---|---|
| `feature_value` | tall — one row per (enterprise, feature, date) | System of record. Auditable, schema-free as features are added. |
| `feature_snapshot` | wide — one row per (enterprise, scoring run) | What the engine and the trainer actually read. |

Tall alone would mean ~5,700 row reads per scoring pass and far worse for
training. Wide alone would mean a migration every time a feature is added.

### 2.3 Point-in-time correctness

Every feature row carries **two** timestamps:

- `valid_for_date` — the date the fact describes
- `observed_at` — when we learned it

A mandi price for 3 March scraped on 7 March must be invisible to a 4 March
scoring run. Without this rule, backtests look excellent and production does not
reproduce them. This is what makes the claim of "no forward leakage across folds"
true rather than aspirational.

---

## 3. Data model

### Master

| Table | Notes |
|---|---|
| `district` | The join key for every external signal. |
| `market` | A mandi, belonging to a district. |
| `commodity` | Maize, soya, egg, milk, wheat… |
| `sector` | The five risk packs, carrying sub-score weights in basis points. |
| `sector_commodity` | Which commodities a sector consumes vs sells. The **input/output** distinction is what makes `margin_squeeze` computable. |
| `role` | RBAC for the console. |

### Enterprise & institutional

| Table | Notes |
|---|---|
| `enterprise` | Opaque id, sector, district, lat/long. No owner name, phone, Aadhaar or account number — the no-PII promise is enforced by schema, not policy. |
| `ledger_entry` | Three-tap entries. `client_id` is generated on the phone so an offline entry keeps identity through sync. |
| `loan_record` | Per loan: sanctioned, outstanding, EMI, due date, **DPD**, bucket. DPD history is the training label. |
| `upi_summary` | Consented transaction aggregates. Source pluggable — Account Aggregator (needs FIU registration under Sahamati), PSP settlement reports, or manual. |

### Signals & features

| Table | Notes |
|---|---|
| `market_signal` | `(district, commodity, week)` — modal/min/max price. ~40 rows a day for four districts, not 142 per-enterprise fetches. |
| `climate_signal` | `(district, week)` — rainfall, tmax, anomalies vs 30-year normal. |
| `feature_definition` | Feature catalogue: code, family, unit, staleness tolerance. |
| `feature_value` | Tall store, with `valid_for_date` + `observed_at`. |
| `feature_snapshot` | Wide store, one per enterprise per run. |

### Scoring & decision

| Table | Notes |
|---|---|
| `scoring_run` | One pass. Carries `model_version` and `source` (`SERVER` \| `ON_DEVICE`) so a historic alert traces to the exact engine that raised it. |
| `forecast_point` | P10 / P50 / P90 and the obligation due, per month, h = 1…6. |
| `stress_score` | Composite 0–100 plus the five stored sub-scores, `engine`, `confidence`. |
| `reason_code` | SHAP driver as a sentence in both languages. Stored, not regenerated, so the wording an officer acted on is preserved. |
| `tripwire_rule` | Configurable rule: SpEL expression over the feature snapshot. |
| `risk_alert` | Raised by the model or by a rule. References the rule and the snapshot, so it is reproducible. |
| `field_visit` | Playbook intervention and its outcome — the feedback edge of the loop. |

### Audit

`api_log` (outbound calls to external feeds), `ingestion_run` (scheduler results,
counts, failures), and `scoring_run` doubling as the model prediction log.

---

## 4. External data — provenance

| Signal | Source | Access | Cadence |
|---|---|---|---|
| Mandi prices | Agmarknet, via the data.gov.in Open Government Data API | API key, JSON | Daily |
| Egg realisation | NECC (e2necc.com) | No API — scrape the daily city rate table | Daily |
| Rainfall, temperature | NASA POWER or Open-Meteo | Free, no key, long history for anomalies | Daily |
| District advisories | IMD Agromet | District-level advisory text | Tue / Fri |
| Milk procurement rate | State dairy federation | No API anywhere — MoU or admin entry | Monthly |
| Institutional extract | Lender CBS / LMS | SFTP CSV or read-only DB view | Nightly |
| UPI aggregates | Account Aggregator (RBI / Sahamati) | FIU registration + consent artefact | Weekly |

IMD supplies the advisory; NASA POWER or Open-Meteo supplies the numbers, because
anomalies need decades of history that live endpoints do not serve.

### Feature derivations

Raw prices are not features. An absolute maize price of ₹2,140 means nothing.

| Feature | Derivation |
|---|---|
| `feed_cost_change` | modal price vs 8-week trailing mean |
| `output_price_change` | same, on the sale-side commodity |
| `margin_squeeze` | input change − output change |
| `price_z_score` | (current − 3yr seasonal mean) / stdev |
| `rainfall_anomaly` | season-to-date vs 30yr normal |
| `heat_anomaly` | days above threshold vs normal |
| `cash_flow_change` | ledger net position vs trailing mean |
| `emi_delay` | DPD from `loan_record` |
| `inventory_days` | stock entries vs sales velocity |
| `upi_inflow_change` | 8-week rolling inflow delta |
| `feed_staleness_days` | age of the newest observation — guards all of the above |

### Degradation rules

- Carry the last known value forward, stamped with `feed_staleness_days`.
- **Trip-wires refuse to fire on stale data.** A rule firing on a three-week-old
  price is worse than no rule.
- Missing shock features fall back to the sector's seasonal prior. The forecast
  widens — P10 drops — which is the honest response to knowing less.
- Scoring never blocks on an external feed. The institutional record and the
  ledger are always present; market data is an enhancement.

---

## 5. Risk and rules

The **risk engine** is rule-based first: a sector-weighted combination of the five
sub-score families, with weights held in the `sector` table so tuning needs no
deploy. It sits behind a `ScoringStrategy` interface, so the LightGBM engine
replaces it as a config change.

The **rule engine** is deliberately independent. `tripwire_rule` rows carry a SpEL
expression evaluated against the feature snapshot:

```
emi_delay > 30 and cash_flow_change < -0.40
```

Business teams edit rows; nobody deploys. SpEL rather than Drools — seven rules do
not justify a rules platform.

A trip-wire alert survives a model retrain. That is the entire point: every alert
stays auditable and explainable independently of whatever the model currently
believes.

---

## 6. Build status

| Area | State |
|---|---|
| Field officer console — 8 screens | ✅ Built |
| Enterprise PWA — 4 tabs, offline, Hindi-first | ✅ Built |
| Ledger + offline queue + sync | ✅ Built |
| Auth, JWT, two scoped surfaces | ✅ Built |
| Serving entities, repositories, services | ✅ Built |
| Master data, controllers, seeder | ◐ Phase A |
| Ingestion (Agmarknet, climate, scheduler) | ✅ Phase B — see §6.1 |
| Feature store + derivations | ✅ Phase C — see §6.2 |
| Risk engine + rule engine + admin API | ✅ Phase D — see §6.3 |
| Console wire-up: rules screen, market panel, freshness | ✅ Phase E — see §6.4 |
| Core banking / LMS connector seam | ✅ Phase F — see §6.5 |
| DPD history: generated + connector backfill | ✅ Phase F — see §6.6 |
| LightGBM quantile heads + SHAP | ○ R1 milestone |

Phases B, C and D each terminate in a table you can inspect, so each is testable
without any of the machine learning existing.

### 6.1 What Phase B delivered

Package `com.lincfusion.udyamlinc.ingestion`.

| Piece | Notes |
|---|---|
| `DataGovClient` | Agmarknet via data.gov.in. Case-insensitive field reads, because the resource's own casing changes between versions. Returns `null` on a failed call and an empty list on a filter that matched nothing — an outage and a typo must not look alike. |
| `OpenMeteoClient` | Reanalysis archive for the district centroid. No key. |
| `MandiIngestionService` | Folds daily arrivals into one `market_signal` per (district, commodity, ISO week). Upserts, so re-running corrects a partial week. |
| `ClimateIngestionService` | Weekly `climate_signal` with the 30-year normal alongside, and `climate_normal` computed once per district from a single baseline request. |
| `IngestionScheduler` | The 02:00 cron. Off by default; one pass at a time; every outcome — including a skip — lands in `ingestion_run`. |
| `IngestionController` | `/admin/ingestion/{runs,calls,signals/market,signals/climate,freshness}`, plus `POST /run` and `/run/{source}`. Reads open to any officer, triggers supervisor-only under the existing `/admin/**` rule. |

Both signal tables carry `valid_for_date` + `observed_at`, and each repository
exposes a `findTrailing(...)` that filters on both — the point-in-time window
Phase C's derivations will read. `/admin/ingestion/freshness` is the staleness
number Phase D's trip-wires must consult before firing.

**Configuration.** `udyam.ingestion.enabled` is `false` by default so a demo boot
never calls out. `udyam.ingestion.datagov.api-key` (env `DATAGOV_API_KEY`) is
required for Agmarknet; without it the run records `SKIPPED` rather than failing.
Climate needs no key.

**Still deferred from §4.** NECC egg rates (no API — needs an HTML scrape), IMD
Agromet advisories, and the dairy federation rate (no API anywhere). Their
commodities are seeded and their `source` values reserved; nothing pulls them yet.

### 6.2 What Phase C delivered

Package `com.lincfusion.udyamlinc.features`, plus the two institutional tables of
§3 the derivations read from (`loan_record`, `upi_summary`).

| Piece | Notes |
|---|---|
| `feature_definition` | The catalogue: family, unit, source kind, direction, and `staleness_tolerance_days` — the column a trip-wire consults before it is allowed to fire. Seeded idempotently at boot. |
| `feature_value` | The tall store. A feature that cannot be computed is written as **null with a `missing_reason`**, never skipped — `NO_SIGNAL`, `NO_LEDGER`, `NO_CBS`, `NO_CONSENT`, `NO_FORECAST`, `INSUFFICIENT_HISTORY`. "We did not know" and "we never looked" are different facts. |
| `feature_snapshot` | The wide store, one per (enterprise, as-of date), carrying `feature_count` / `missing_count` / `max_staleness_days` so a snapshot mostly made of holes cannot read as confident. `asFeatureMap()` exposes the same values under their snake_case codes — the shape a SpEL rule is written against. |
| `FeatureEngineeringService` | All fourteen derivations. Every read is point-in-time on both `valid_for_date` and `observed_at`, so recomputing last month uses only what was knowable last month. |
| `FeatureController` | `/admin/features/{definitions,snapshot/{id},values/{id},coverage}` and `POST /compute`, `POST /compute/{id}`. `coverage` reports the populated share per feature — a feature at 4 % coverage is a column, not a feature. |

**Catalogue.** §4's eleven, plus three the seeded trip-wires already named:
`dscr_p10` (worst month of `min(p10 / obligation)` over the latest run),
`days_since_last_entry`, and `emi_to_inflow`. A rule referring to a feature
nobody computes is a rule that silently never fires. These three also give the
OBLIGATION_LOAD family the inputs it otherwise lacked.

**Demo inputs.** The seeder now writes one `loan_record` per enterprise with DPD
tracking the band, so `emi_delay` and `emi_to_inflow` are real without a CBS
feed. `upi_summary` has an entity and a point-in-time query but no source until
Account Aggregator registration — `upi_inflow_change` therefore resolves to null
with `NO_CONSENT`, which is the honest answer and exercises the degradation path.
Price and climate features stay null until Phase B has actually run.

### 6.3 What Phase D delivered

Packages `rules` and `risk`.

| Piece | Notes |
|---|---|
| `RuleEvaluator` | SpEL over the feature rows, in a `SimpleEvaluationContext` restricted to property access — these expressions are authored by business users, so no method calls or bean lookups. Compiled expressions cached by rule code **and version**, so an edit invalidates its own entry; the admin write endpoints also clear the cache. |
| `RuleOutcome` | Every rule returns FIRED / NOT_FIRED / SKIPPED_STALE / SKIPPED_MISSING / SKIPPED_SECTOR / ERROR. "No alert because the enterprise is fine" and "no alert because the feed has been down a fortnight" must never look the same. |
| `ScoringStrategy` | The seam the model arrives through. `udyam.risk.engine` binds the implementation; LightGBM later is that one line. Implementations read features and nothing else — no reaching back into the signal tables. |
| `RuleBasedScoringStrategy` | Five families onto 0–100, combined with the sector's basis-point weights. Each family takes its **worst** signal, not the mean — averaging lets a calm dimension mask an acute one, and the acute one is where the officer needs to go. |
| `RiskEngineService` | Compute features → score → evaluate trip-wires against the **same feature rows, never the score** → persist score, top-3 reason codes, alerts. |
| `RiskEngineController` | `POST /admin/scoring/run`, `/run/{id}`, `GET /admin/scoring/runs`, and `GET /admin/scoring/explain/{id}` — every rule's outcome with no writes. |
| `ScoringScheduler` | 03:00, an hour behind ingestion so it scores what that job wrote. Off by default. |

**The staleness gate.** Before any expression runs, each of a rule's
`requiredFeatures` must have a value and be within the **stricter** of the rule's
`maxStalenessDays` and the catalogue's per-feature tolerance — a supervisor
tightening a rule must not be overridden by a generous default. This is the
promise of §4's degradation rules, enforced rather than documented.

**Band versus score.** A fired trip-wire escalates the band; it never rewrites
the score. They answer different questions — "how stressed is this enterprise"
and "has a specific agreed line been crossed" — and an audit needs both.
A family with no usable feature falls back to `udyam.risk.family-prior` rather
than scoring zero, because zero reads as "safe here" when the truth is "unknown",
and each family on a prior costs confidence.

**What the seeded rules can actually do today.** TW-01 (`dscr_p10`) and TW-03
(`days_since_last_entry`) evaluate from seeded data. TW-04 (`emi_to_inflow`)
evaluates once loan records exist, which the seeder now writes. TW-02
(`upi_inflow_change`) and TW-05 (`price_z_score`, `heat_anomaly`) will report
SKIPPED_MISSING until Account Aggregator consent and Phase B ingestion
respectively — visibly skipped, which is the intended behaviour rather than a
silent no-op.

**Not built here.** The quantile forecast is still the seeded path; this engine
scores and alerts but does not produce `forecast_point` rows. `dscr_p10` reads
whatever the latest run stored. Generating forecasts is part of the R1 model
milestone.

### 6.4 What Phase E delivered

In `UdyamLinc-UI`, two console screens and one piece of chrome — all three about
provenance, because the failure mode that matters is silent. A score computed
from a three-week-old mandi price looks exactly like one computed this morning.

| Piece | Notes |
|---|---|
| `features/officer/DataFeedsPage.tsx` | `/officer/feeds` — freshness per district first, then the mandi panel, the rainfall/heat panel with the 30-year normal beside each observation, and the ingestion run log. A skipped run appears as a row, so "nothing ran last night" never reads as "it ran and found nothing". |
| `features/officer/RulesPage.tsx` | `/officer/rules` — every trip-wire with its expression and tolerance, its outcome for a chosen enterprise, and the feature snapshot underneath with each null's reason. A banner counts rules that could not run. |
| `FreshnessChip` in `OfficerShell` | Data age in the header on every screen, amber past ten days, linking to the feeds page. |
| `lib/demo/feeds.ts` | Demo fallback that applies the **same two guards in the same order** as `RuleEvaluator` — missing, then stale, then the expression — so the offline demo cannot claim a rule fired that the real engine would have skipped. |

Both screens follow the house pattern: `useQuery` against the real endpoint,
in-file demo fallback, and a "Demo data" pill when the backend is unreachable.
`npm run build` and `oxlint` are clean.

**Deliberately not added:** rule *editing* from the console. The backend accepts
`POST`/`PUT /admin/rules` and bumps the version on every edit, but a supervisor
changing a live threshold from a demo build with no audit trail in front of it is
a worse idea than the round trip through an API client.

---

### 6.5 What Phase F delivered

Package `com.lincfusion.udyamlinc.connector`, plus `/officer/integration`.

**The problem it answers.** The loan book is the training label and the one input
no public feed supplies. Integrating with a lender's core is not a technical
unknown — it is an onboarding process per bank, with a schema agreed in a room.
There is no single integration to build ahead of that room. What can be built
ahead of it is the shape of the seam, and that is what this is.

| Piece | Notes |
|---|---|
| `CoreBankingConnector` | Fetches and returns rows. Never writes — an adapter that could write would be an adapter that could bypass the no-PII rule. |
| `FileDropConnector` | **The one that is real.** Reads the newest matching file from a drop directory a bank delivers to. Leaves the file where it found it, so a failed run is repeatable. |
| `SimulatedCoreConnector` | CBSNexora — LincPay's own core banking platform — emitting the real portfolio in its own field names. Rows derived from real enterprises and loan records, drift seeded from the account ref so an extract is reproducible. **No third-party core banking product is named anywhere in this system;** where a lender runs someone else's core, the per-profile field mapping absorbs their column names. |
| `FieldMapper` | `{canonical_column: vendor_column}`. Validated before it is stored, not at the next nightly run. |
| `ConnectorSyncService` | Fetch → map → **`LoanBookEntryService.stage`** → run record. |
| `ConnectorProfile`, `ConnectorSyncRun` | Per-bank configuration and per-attempt audit. |
| `features/officer/IntegrationPage.tsx` | Connections, field mapping, sync history. Simulated adapters badged everywhere they appear. |

**Three decisions worth keeping.** The mapped rows go through the validator the
manual upload already had rather than a second one written for the automated
path — the obvious shape would be a parallel validator, and it would eventually
enforce the no-PII rule differently. Unmapped vendor columns are dropped because
the map is keyed by canonical name, which makes the promise structural rather
than remembered. And `simulated` is stamped per run rather than read from the
profile, so switching a profile to a live adapter cannot retroactively make its
old runs look real.

**One real defect this surfaced.** `FORBIDDEN_COLUMNS` was matched by exact
normalised name, so `CUST_NAME` — a column name real extracts do carry — was not
caught, and a directly uploaded bank file would have kept the borrower's name in
`manual_entry_line.raw_row`. Matching now also splits separators and camelCase.
That fix belongs to the manual upload path as much as to the connector.

**Still not built:** SFTP polling with credentials (the drop is assumed mounted or
synced by something the bank already runs), scheduled execution (`scheduleCron` is
recorded and read by nothing), and incremental watermarks.

### 6.6 DPD history — the training label, and where it comes from

Package `com.lincfusion.udyamlinc.loanhistory`, plus a fourth tab on
`/officer/integration`.

The book held **one snapshot per loan**, so there was no history at all and
nothing a model could be trained against. Two routes now fill it, and the
difference between them is stated rather than implied.

| Route | What it is |
|---|---|
| `LoanHistoryService.generate` | Synthetic monthly snapshots, every row stamped `SEEDED_HISTORY`. Exercises the feature store, the point-in-time joins and the label plumbing before a bank has delivered anything. |
| `ConnectorSyncService.backfill` | One extract per month across a range, mapped and staged as a single batch. This is the real path: every core can answer "what did the book look like at each month end last year". |

**Provenance is the whole design.** `LoanRecord.source` is stamped at every write
site, and coverage reports **three** buckets — synthetic, real, unknown — never
folding unknown into real. Generation refuses to overwrite an existing row, so a
lender's extract survives a regeneration.

**The generator's arithmetic had to be got right, and was not at first.** Real DPD
steps: pay and cure to zero, or miss and roll forward one instalment period. The
first version added day-of-month slack **per month**, so consecutive months
differed by anything from 1 to 59 days — a shape no loan book produces, and one
that would have taught a model a nonsense transition matrix. The slack is now
fixed per delinquency episode (a due date does not move between two missed
payments), and for the run reaching the anchor it is derived from the anchor's own
DPD so the series joins today's number exactly. Verified against a running
instance: every generated series now rolls by exactly 30, and the only steps that
are not are the joins to pre-existing rows the generator correctly refused to
touch.

**What this does not claim.** With no lender extract on the book, coverage reports
`trainable: false` and says so in words. Training on generated history and
reporting the accuracy would be measuring the generator.

---

## 7. Explicitly not being built yet

Kafka, Neo4j, Elasticsearch, Keycloak, MinIO, and separate deployables. All appear
on the submission's technology slide; none earn their keep at four districts.
Postgres plus a scheduled job carries the pilot comfortably. Kafka arrives when
ingestion volume or a second consumer demands it — not before.