Version 0.1.1
An open, exploratory framework for examining how instability develops across connected parts of human life and how people and systems might respond earlier, more clearly, and more responsibly.
In plain language: this is a set of foundations, reasoning roles, safeguards, examples, and feedback tools for seeing how pressures such as housing, work, transportation, childcare, health, income, and access to services can interact, so people and systems can coordinate support earlier without reducing a person to a score.
My dad used to tell me, "You're only as smart as the tools you know how to use, and if the tool doesn't exist, build it." I've carried that with me for a long time.
This project is my attempt to build something I wish had existed during one of the hardest chapters of my life. Back then, I didn't need another person telling me what was wrong. I needed someone who could see how everything was connected, help me understand what was starting to fall apart, and help me find a way forward before every problem became a crisis.
That is what this work is trying to become.
It is still early, and I expect parts of it to change as people test it, challenge it, and show me where it does not work. That is the point of opening it up. If you work in this space, have lived experience, build systems, support families, study human services, or simply see something I missed, I want you involved.
People rarely experience one problem at a time.
A housing issue can create a transportation problem. Transportation can affect work. Work can affect income. Income can affect childcare, food, communication, healthcare access, and the ability to meet ordinary obligations.
Systems can also look resource-rich on paper while still leaving people with very little they can actually use. A program may exist, but that does not mean it is available when someone needs it or usable in that person's real circumstances.
That is why this work separates resource presence, resource availability, and resource usability.
A service can technically exist and still be out of reach because of a waitlist, staffing shortage, transportation problem, eligibility rule, limited hours, funding restriction, or failed handoff.
None of that is a new discovery. This project is an attempt to make those connections easier to see and discuss before several manageable problems become one large crisis.
The question behind the repository is whether we can get better at seeing those relationships early enough to coordinate useful support without turning a human life into a score, prediction, label, or automated decision.
These terms are related, but they are not interchangeable and they are not stages a person moves through.
- Human Standability looks at whether a person can maintain day-to-day function while pressure is building across different parts of life.
- Organic Stability Intelligence widens the view to the systems, environments, organizations, and relationships around that person.
- Stability Intelligence asks how meaningful changes in stability can be understood without pretending one number can explain a human life.
- Stability Infrastructure looks at the connective structures that may help fragmented systems coordinate, preserve continuity, and make existing resources genuinely usable.
The fuller definitions are in the foundations folder.
In these names, "intelligence" means understanding, not surveillance. Nothing in this framework supports monitoring individuals or collecting more information about people than a stated purpose requires.
The related research underlying this framework has already been developed in the associated papers, including cited comparisons with recovery capital, integrated care, systems of care, case management, social determinants of health, prevention science, implementation science, network governance, continuity of care, reentry coordination, resilience, and related fields. This repository does not reproduce that full literature review. It is focused on making the framework usable, reviewable, and testable in practice.
This repository contains conceptual foundations, reasoning roles, safeguards, field-feedback templates, and examples that can be used to examine stability-related problems from several perspectives.
The role files can be used as structured prompts with AI systems or as review guides for human teams. They are not autonomous authorities, professional substitutes, or decision makers. Their purpose is to help people ask better questions, identify missing information, challenge assumptions, and examine how different pressures may interact.
If you use these roles with an AI tool, do not paste identifying participant information, case-file details, medical identifiers, legal identifiers, or other information that could reasonably identify a person. Use synthetic or properly de-identified information and follow the privacy rules that apply to your setting.
The framework does not require every organization or community to use the same services, terminology, workflow, or technology. Local context matters, and any implementation should remain open to correction.
Human Stability Infrastructure is not a validated assessment instrument, diagnostic system, predictive model, clinical protocol, legal standard, sentencing tool, eligibility mechanism, supervision score, surveillance platform, or automated decision system.
The frameworks documented here remain exploratory and require independent research, field testing, criticism, and revision.
CORA may eventually provide one operational environment for some of these ideas, but CORA is not the same thing as Human Stability Infrastructure and should not be treated as proof that the underlying concepts work.
At this stage, there is no Human Stability score.
The framework can examine observable conditions and changes, such as whether transportation is available, whether a service can actually be reached, whether a handoff failed, whether a waitlist changed, or whether the participant reports that a pressure is getting better or worse.
Those observations may be counted or tracked over time when that is useful, and compared to describe conditions and systems, such as wait times across services. They should not be used to rank, sort, or label people, and they should not be collapsed into a hidden score.
If future versions introduce any formal measures, they should be transparent about what is being measured, open to participant correction, specific to the purpose, and tested before anyone claims they are valid.
Version 0.1.1 documents the current conceptual structure and gives reviewers something concrete enough to challenge.
The repository currently includes:
- working definitions for Human Standability, Organic Stability Intelligence, Stability Intelligence, and Stability Infrastructure;
- six principles intended to keep implementation centered on people rather than systems;
- five portable reasoning roles that can be used by people or AI-assisted workflows, all governed by the same shared safeguard baseline;
- one shared safeguard baseline that applies across every role, template, example, and future tool;
- field-feedback templates designed to capture failures and practical lessons without collecting identifying participant information; and
- one fully synthetic example showing how the pieces can be used together.
Several important questions remain unanswered. The framework has not established validated measures, causal relationships, predictive accuracy, universal intervention sequences, or evidence that using these materials improves outcomes.
Those are research questions, not assumptions this repository is allowed to make.
Where does this break in real implementation?
I am interested in places where the framework becomes confusing, impractical, duplicative, unsafe, insensitive to local realities, or simply wrong.
A useful failure report is more valuable to this project than polite agreement.
If you are new to the project, begin with:
- this README;
- the synthetic worked example;
- the shared safeguard baseline;
- the foundations overview; and
- whichever reasoning role is most relevant to your work.
The synthetic example comes early on purpose. The framework is easier to understand once you can see how the different perspectives behave around the same fictional situation.
If you need a shorter plain-language introduction for a meeting, email, or first review, see the short overview.
Lived experience helped generate many of the questions behind this work, but one person's experience is not a universal model.
The repository should grow through the experiences of people who have received services, provided services, built systems, conducted research, managed programs, challenged institutions, and watched well-intended approaches fail.
No contribution becomes correct merely because it came from lived experience, professional credentials, institutional authority, or this repository's author. Claims should survive scrutiny regardless of where they came from.
This repository uses different licenses for different kinds of material.
- Written documentation and other non-code materials are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0) unless a file clearly says otherwise. The full license text is in LICENSE-DOCS.md.
- Software source code, when code is added and identified as software, is licensed under Apache License 2.0 unless the file clearly says otherwise. The full license text is in LICENSE-CODE.md.
- The root LICENSE file explains this split so one license is not mistaken for covering every future file in the repository.
These licenses do not grant rights to project names, logos, branding, or trademarks. See TRADEMARKS.md.
CC BY 4.0 requires credit and a note of any changes. A suitable form is:
Based on Human Stability Infrastructure (v0.1.1) by Jeff Mendenhall, https://github.com/PhoenX2000/human-stability-infrastructure, licensed under CC BY 4.0. [Describe your changes.]
If you test these materials in practice, I would also appreciate hearing what helped, what failed, and what had to be changed. That feedback is more useful to this project than simply knowing the materials were used.
Contributions are welcome from researchers, practitioners, people with lived experience, technologists, public agencies, community organizations, students, critics, and anyone else who can help make the work more useful and more responsible.
For implementation feedback, use the Implementation feedback issue form.
For a challenge to a definition, assumption, boundary, or claim, use the Framework challenge issue form.
For a small correction or proposed change, a pull request is welcome.
For privacy, safety, or conduct concerns that should not be public, do not post identifying details in an issue. Email phoenx2025@gmail.com with only the type of concern and enough information to arrange a safer way to continue. The Code of Conduct explains this more clearly.
Please read CONTRIBUTING.md before submitting changes or field feedback.
Jeff Mendenhall
Human Stability Infrastructure
Version 0.1.1