4.0 Decision Intelligence Framework: four research projects under one evidence rule

What the rebuild is trying to fix

The README opens with a self-critical observation: the repository whose name matches the endeavor phrase most closely is the one least aligned with it. This rebuild makes the name true, with optimization-driven, system-level decision frameworks as the goal.

It is part of a five-repository portfolio supporting an endeavor described as the EB2-NIW petition, and the framing is explicitly about domains where a wrong decision carries systemic consequences. Three pillars are named: financial stability, healthcare safety and secure digital infrastructure.

There is a small table in the README that captures the diagnosis. Petition-grade projects today: 0 original, NIW-relevant projects. Verdict: rebuild around its own name.

And then the definition of what petition-grade means, which is the most useful paragraph in the document. It means original work, a stated method, real data at a stated scale, a measured result, and a README a reviewer can follow. Counts exclude duplicates, forks of third-party work, retired projects and asset-only folders.

That exclusion list tells you what the author considers not worth counting, and it is a stricter bar than most research portfolios set for themselves. A fork of someone else's work, even a useful one, does not count. So the projects here are the ones the author claims as original, and the four directories are each defended in the same way, with a stated reason for why it earns its place.

The primary language is Python, the licence is not stated, there are no GitHub releases, and the last push was on 2026-10-18. The test badge in the README points at a GitHub Actions workflow, so there is a test suite somewhere in the tree even if the top level does not show it.

The optimization library and the decision-audit framework

The first two projects are cross-cutting, and the README marks both as CORE.

The Optimization-Under-Uncertainty Library lives in 2-optimization-under-uncertainty/ and applies optimization under uncertainty to portfolio allocation and hospital resource allocation. Its stated reason for existing is that it is the Cornell ORIE training expressed as code, and that the petition's Version 3 rests entirely on that framing with nothing to point at. The target scale is portfolio allocation and hospital resource allocation instances.

The Decision-Audit Framework lives in 1-decision-audit-framework/ and covers decision logging, counterfactual replay and attribution for AI-assisted decisions. Its justification is the sharpest of the four: it makes the phrase auditable, interpretable decision frameworks into an artifact rather than a phrase. The target scale is decision traces from the other projects in the repository.

The pairing matters. The optimization library produces decisions, and the audit framework records and explains them, and the target scale line for the second project says it will draw on the decision traces from the others. That is a closed loop across two subdirectories, and it is the reason the numbering is out of order, with 2-optimization-under-uncertainty listed first in the table and 1-decision-audit-framework second.

The counterfactual replay element is the technically interesting part of the audit framework. Logging a decision is straightforward, and attribution is a known hard problem, but replaying what would have happened under a different input is what turns a trace into an explanation. A trace that records only the chosen action tells you what happened; a trace that can be replayed against a counterfactual tells you whether the choice was justified.

The two remaining projects are where the domain pillars attach.

The ICU triage project and the benchmark suite

The third project is the one that ties a pillar to a concrete domain.

The Multi-Objective ICU Triage Optimization lives in 3-icu-triage-optimization/ and covers multi-objective ICU triage and alert-threshold optimization. Its stated reason for earning its place is that it connects the healthcare pillar to the operations-research framing, which the README calls the weakest join in the petition. The target scale is MIMIC-IV and eICU cohorts, shared with the second repository in the wider portfolio.

Sharing the cohorts with another project is a deliberate design choice rather than a convenience. It means the triage optimizer and the optimization library work on the same underlying data, so results can be compared rather than each living on its own dataset.

The fourth project is the Decision-Framework Benchmark Suite in 4-decision-benchmark-suite/, covering regret, calibration and stability benchmarks across the frameworks in the repository. Its justification is that a benchmark is the most citable form of contribution and the easiest for others to adopt, and the target scale is all frameworks in the repository.

Those three axes are the right ones for judging a decision system, and the choice of them says something about the author. Regret is the loss relative to the best available alternative, which is the metric that matters when comparing decisions made under uncertainty rather than predictions against ground truth. Calibration is about whether a stated confidence matches the observed frequency, which is what you need to set an alert threshold responsibly. Robustness is about behaviour when the input distribution shifts, which is the normal condition in a socio-technical system rather than an edge case.

The benchmark suite is also the piece most likely to be used by someone who never reads the rest, since a benchmark is a thing other people run rather than a thing they learn from.

The four ground rules, which are the real content here

The ground rules section is short and it is the part of this repository that distinguishes it from a collection of research code.

The first rule is that there is no number without a run log. Anything cited in the petition must appear in that project's results/README.md with a run date behind it. The second is no simulated data under a real claim: sample data lives in a sample directory, is labelled, and is never the source of a cited figure.

The third is that adoption must be documentable, with named institutions, dated correspondence and registry statistics, and never an inflated count. The fourth is that third-party and forked code stays labelled and is never counted.

Taken together, these four rules are a research integrity policy expressed as build constraints. A figure cannot exist without a dated run behind it. Sample data cannot masquerade as real. Adoption claims need receipts. And borrowed code has to say so.

That last rule is what makes the earlier table about zero petition-grade projects meaningful. If forks do not count, then the portfolio had to be built rather than assembled, and the rebuild is the response to that.

The rules also explain the physical layout. Every rebuilt project carries the same skeleton of README.md, src/, data/, results/, tests/ and website/. The results/ directory is where the run logs live, and the tests/ directory is where the badge in the README comes from. A uniform skeleton means a rule like the first one can be checked the same way in every subdirectory.

One closing note under the layout, and it explains the archive directory. Earlier and off-theme prior work, described as dashboards, consumer apps, templates and other non-endeavor folders, has been moved to a separate archive-prior-work repository to keep this one focused, and it remains recoverable from the git history.

The honest state of the repository, and what the scaffold says

The last line of the README is the one to read before you cite anything here.

The scaffold was generated from a spreadsheet called NIW_Project_Portfolio_and_Gap_Plan.xlsx, with the sheet names given as Repo Build-Out Plan, Core Ideas at a Glance, NIW Claim vs Repo Evidence, and an alignment sheet. And the closing sentence is explicit: structure only, no results are claimed here yet.

That is an unusual thing to find in a README, and it is the correct thing to find, because it separates the two things that are easy to confuse. The structure exists, the ground rules exist, the skeleton exists for each project, and the evidence does not exist yet. The rule about no number without a run log only means something if there are moments where you have to resist producing a number, and this README is one of those moments.

The top level listing is consistent with that state. There are the four project directories, a .github directory, a README.md, a .gitignore, a historical-archive/ directory, a spreadsheet file named Project_Core_Ideas_Summary.xlsx, and a .DS_Store that got committed by accident.

For a reader deciding what to do with this, the practical reading is that it is a well-organised plan with a set of evidentiary standards attached to it, and that the standards are the durable part. If you are building something similar, the four rules and the uniform per-project skeleton are reusable regardless of whether you use the specific projects, and the ICU triage and decision-audit projects are the two that a working healthcare or AI governance team would look at first.

Editorial conclusion

Adopt this repository if you are working on optimization-driven decision support with an interest in auditable AI decisions, and you want worked examples of the four patterns it holds together. Do not treat it as a validated library to install, because the README states that no results are claimed yet and that the scaffold is structure only. Before citing anything from it, check the run log rule: any figure you use has to appear in that project's results directory with a run date, and sample data is never the source of a cited number.

Frequently asked questions

Official sources

1. evelyyyyynnnnn/4.0-Decision-Intelligence-Framework on GitHub
2. Issues
3. README