From a research question
to a defensible result.

Ask for: a linear model with outcome nim_nii_avg_assets and predictors net_npa_ratio, ln_total_assets, crar. Since your six banks are observed repeatedly, also pass an entity column (bank) as clusterColumn — otherwise the model wrongly assumes every bank-year is an independent observation, when in fact a bank's own errors are correlated across its own years.

Read it as: the coefficient on net_npa_ratio is the estimated change in margin per one-unit rise in the NPA ratio, holding size and capital fixed. Check the clustered p-value, not the plain OLS one, once you've clustered. Then check maxVif — above 10 means size and capital are too entangled to trust their individual coefficients — and the new residualDiagnostics: a Breusch-Pagan/White rejection means your standard errors (even the clustered ones) may still understate uncertainty; a RESET rejection means the true relationship probably isn't a straight line.

When you'd reach for this: the linear model above came back with VIF over 10 on ln_total_assets and crar — larger banks in your sample also happen to hold more capital, so the model can't cleanly separate "size effect" from "capital effect." Dropping one throws away real information; ridge keeps both but shrinks each coefficient toward zero in proportion to how collinear it is.

Read it as: compare each predictor's shrinkagePct. A predictor that barely shrank wasn't actually the collinear one; a predictor that shrank heavily was. There are no classical p-values here — ridge trades a small, known bias for a large reduction in variance, so judge it by shrinkage and by how much the sign and rough size of each coefficient held up, not by significance stars.

Why you'd want this instead of clustering: clustering (example 1) fixes the standard errors but still assumes each bank's average margin, once size and capital are accounted for, is the same. That's a strong assumption — maybe one public-sector bank is just permanently less efficient for reasons your data can't see. Fixed effects removes that: it estimates the relationship using only each bank's deviations from its own average over time.

Ask for: kind fixed_effects, with dateColumn: "fiscal_year" and idColumns: ["bank"] — a panel model has to know both which period and which entity each row belongs to.

Read it as: there's no Intercept — each bank's permanent level is absorbed, not reported — so this can't score a brand-new row (see "Predicting," below). The Hausman test alongside it answers a different question: was fixed effects even necessary? If it doesn't reject, your bank-specific differences probably aren't correlated with NPA/size/capital, and random effects (example 4) would have given you a more efficient (lower-variance) estimate for free.

Ask for: kind random_effects, same columns as example 3. It runs both estimators internally and reports one Hausman test either way, so you can build this first and let the test tell you which coefficients to actually trust.

Read it as: if Hausman rejects (p < .05), trust the fixed_effects coefficients instead — random effects is inconsistent whenever entity differences correlate with your predictors, which is exactly what rejection means. If it doesn't reject, random effects is valid and more efficient, and — unlike fixed effects — it does report an Intercept, so it can be used with predict_with_model.

The problem this solves: every model above assumes net_npa_ratio is exogenous — that it isn't itself a symptom of the same hidden cause as low margins. That's often false: a bank might report more NPAs precisely because it's already struggling for unrelated reasons (reverse causality), or some unmeasured management-quality factor could drive both. If so, every coefficient above is biased, no matter how many controls you add.

Ask for: kind iv2sls, endogenousColumns: ["net_npa_ratio"], and an instrument — a variable correlated with NPA ratio but with no direct effect on margin except through it. (A real instrument takes domain judgment; this is illustrative, not a recommendation: something like a regional stress indicator that affects asset quality but doesn't directly touch margin-setting.) crar can serve as an exogenous control alongside it via predictorColumns.

Read it as, in this order: first weakInstruments — a partial F-statistic under 10 (the Stock-Yogo rule of thumb) means your instrument barely moves the endogenous variable, and everything downstream is unreliable. Then endogeneityTest (Wu-Hausman) — if it doesn't reject, plain OLS wasn't actually biased here, and it's more precise; use it instead. Only if both pass should you trust the IV coefficient over the olsCoefficient shown alongside it. If you supplied more instruments than endogenous regressors, also check overidentification (Sargan) — a rejection there means at least one instrument is probably invalid.

GMM: ask for kind iv_gmm with the same arguments as example 5. It's the more statistically efficient choice specifically when you have more instruments than endogenous regressors (overidentified) — with exactly one instrument for one endogenous regressor, 2SLS and GMM coincide.

Panel IV: if your instrument's validity itself depends on removing permanent bank-level differences — not just because the data happens to have banks in it — add panelEntityEffects: true and idColumns: ["bank"]. This demeans the outcome, controls, endogenous regressor and instrument by bank before running 2SLS/GMM on what's left (the technique statisticians call "within-IV"). Like fixed effects, entity effects are absorbed rather than reported, so this can't be used with predict_with_model either. Reach for it specifically when a plain IV instrument seems correlated with something permanent about the bank — not as a default.

No. Start with the research question and review the proposed methodology. The descriptions and assumptions remain visible so you can make an informed choice.

No. Registered quantitative tools execute through the deterministic analysis kernel. AI may explain the results it receives.

No. The platform measures data and evidence. It does not recommend transactions, allocations, target prices or investment decisions.

Common causes are insufficient observations, incompatible column types, identical variables, missing time ordering or assumptions that the selected data cannot satisfy.

Use Save project to export the data, cleaning pipeline, lineage and Notebook. Restore that project in a future session.

A finding (section 07) is a write-up of a one-off result — useful as a record, but not something you can hand new data to. A saved model (section 08) keeps the actual fitted coefficients, so you can reopen it, compare it to other specifications, and — for most kinds — score a brand-new row with predict_with_model.

Fixed effects (and panel IV with panelEntityEffects) work by removing each entity's permanent level from the data before fitting — that level is never estimated as a number you could add back in for a new row. Build a random-effects or plain (non-panel) model instead if predicting on new data matters to you.

A partial F-statistic under 10 means your instrument doesn't move the endogenous predictor enough to identify its effect reliably. Look for a stronger instrument rather than trusting the coefficients as reported — a weak instrument can produce estimates further from the truth than plain OLS.