Main analytical backbone
Clinical product
Comparative modeling
Cloud-ready inference
Clinical product showcase
CKD prediction turned into a clear, polished product flow.
This experience is designed as a finished system surface: a public showcase that explains the evidence, and an operational workspace that can move structured intake into local or cloud-connected prediction.
Held-out split
Clinical route plus research route
Workspace preview
Operational interface
Open app
36%
Dataset #336 drives the core predictive product path.
Baseline models and AutoPrognosis were compared on the same held-out split so the evidence surfaced in the product remains traceable and coherent.
Dataset #857 is integrated carefully, not oversold.
Its role is supplementary harmonized analysis and supplementary validation with explicit caveats, not a strict external validation headline claim.
Explanation and operation are separated on purpose.
The public showcase explains the system and its evidence; the workspace handles actual structured prediction flow.
Workflow logic
The finished system works like a connected product, not a pile of research fragments.
The interactive navigator below walks through the same logic the product follows: data discipline first, model comparison second, service orchestration third, and deployment posture last.
Data discipline
Schema, target logic, and harmonization decisions are fixed before the product layer begins.
The product rests on aligned analytical inputs rather than ad hoc field mixing. Dataset #336 remains the primary development set, while dataset #857 passes through representation review, usability tiers, and conservative harmonization before entering any supplementary path.
- Unified binary
targetdefinition. - Shared schema defined before aligned exports.
- Missingness preserved outside the modeling pipeline.
Comparative modeling
Baseline models and AutoPrognosis are presented as complementary evidence, not competing black boxes.
The finished system keeps the strongest parts of each approach visible: transparent baseline performance, AutoPrognosis workflow output, and a clear comparison on one held-out split. That lets the product explain why it exists instead of simply stating that it predicts.
- Baseline branch includes logistic regression, random forest, and HistGradientBoosting.
- AutoPrognosis is preserved as a distinct training and selection workflow.
- Performance and calibration are shown together rather than reduced to AUROC alone.
Operational service
The interface is built for real prediction requests, not static demo storytelling.
The product separates a public showcase from the actual workspace. Inside the workspace, clinical intake mode and research inference mode coexist so the system can grow into a product without losing alignment with the current model line.
- Public-facing showcase for explanation and trust.
- Operational workspace for intake, response rendering, and adapter control.
- Direct handoff to local or cloud-served endpoints when available.
Deployment posture
Cloud readiness is built into the product, but the architecture stays honest about its boundary.
AWS remains the primary architectural reference for storage, model artifacts, serverless inference, and future service operations. At the same time, the frontend stays lightweight enough to remain a static interface that can point to different backend routes over time.
- Static frontend suitable for S3 and CloudFront delivery.
- Inference handoff compatible with API Gateway, Lambda, or a local backend.
- Cloud, on-premises, and hybrid options remain context-dependent.
Evidence
The interface is supported by measured results, and the strongest numbers are still treated with caution.
This layer turns your finished modeling outputs into a product-readable evidence surface: short enough to scan, specific enough to defend.
AutoPrognosis evidence
Held-out split
1.000
AUROC on dataset #336
AUPRC
1.000
Accuracy
1.000
Brier
0.021
| Model | AUROC | Accuracy | Brier |
|---|---|---|---|
| Logistic Regression | 0.977 | 0.938 | 0.055 |
| Random Forest | 1.000 | 1.000 | 0.008 |
| HistGradientBoosting | 1.000 | 0.988 | 0.005 |
No obvious leakage in quick sanity checks.
Train/test overlap and exact duplicated feature rows were not detected in the quick integrity pass.
Strong performance is not treated as automatic proof of generalization.
The main dataset may still be intrinsically easy, and several renal markers carry strong clinical signal.
#857 remains supplementary.
The secondary dataset informs harmonized supplementary analysis rather than a strict external validation headline.
Product surfaces
This experience is deliberately split into a showcase layer and a working layer.
That split makes the product feel more mature: one surface explains the system, the other does the job.
Explain the system before asking anyone to trust it.
Use the public-facing page to show the research logic, evidence posture, platform architecture, and why the interface exists.
Run the operational prediction flow in a separate, cleaner surface.
Clinical intake mode and research inference mode sit in the same workspace, but they are honest about their assumptions and routing.
Keep the frontend static while the backend evolves behind it.
The interface can later point to local services, API Gateway, Lambda, or other cloud routes without rewriting the whole frontend.
Launch
Go from the story to the actual prediction interface.
The showcase explains the why. The workspace handles the doing. Keeping those two surfaces separate is what makes the platform feel like a real product instead of a stitched-together thesis page.