OPEN HONEST FOUNDATION
Mission
The Open Honest Foundation, Inc. is organized exclusively for scientific, literary, and educational purposes within the meaning of Section 501(c)(3) of the Internal Revenue Code. The Foundation conducts pre-registered empirical research on the rigorous measurement and reliable production of verifiable software; conducts and disseminates research on the methodology of empirical inquiry itself; develops and disseminates open educational materials; publishes open technical standards that codify the research; operates a practitioner certification program that attests to competence in the methodology; and will certify implementations of its standards as conforming to them.
Any software, measurement instruments, or computational platforms developed by the Foundation exist as the means by which the research and educational programs are delivered. They are not the Foundation's mission.
The public-interest problem
Software decides things the public has to live with. Scientific computing informs policy. Financial systems allocate capital. Clinical decision-support tools shape care. Voting systems, civic infrastructure, accessibility platforms, and regulated-industry workflows all depend on code behaving as someone claimed it would. Whether that software can be trusted is a matter of public concern.
After decades of professional practice, the field has no rigorous, registered, falsifiable, generally accepted standard for code quality. Code written by AI arrived at scale before that gap was closed, and the gap is now urgent.
THE GRADERS HAVE GONE UNGRADED
In 2026 the benchmark company Datacurve audited SWE-bench Pro, one of the most-cited benchmarks for code written by AI, across 789 reviewed trials. It reported that the benchmark's verifier marked 8.5 percent of wrong solutions as passing and 24 percent of correct solutions as failing, and that it disagreed with an independent analyzer on 32 percent of trials. The audit also found agents reading the reference solution out of the repository's own commit history, with those runs recorded as passes. The scores had been public and widely cited for a long time before anyone checked the grader.
What already exists, and what it misses
Two international standards address software quality.
ISO/IEC 25010 is a quality model. It defines desired characteristics such as reliability and maintainability and sorts them into a hierarchy. It sets out no measurement or compliance regime. Practitioners report that the definitions are loose enough for two readers to disagree and for both to stay inside the standard.
ISO/IEC 5055, published in 2021, supplies the measures. It counts occurrences of specified critical weaknesses across four characteristics, mechanically, through static analysis.
The security and reliability measures are grounded in evidence, because the reliability measure counts 74 weaknesses drawn from the Common Weakness Enumeration, a catalog built from documented incidents. The maintainability measure is not. It counts cyclomatic complexity, which is the number of decision branches in a piece of code, along with component size and duplication. The field adopted all three because they seemed plausible. Cyclomatic complexity has a stable linear relationship with lines of code, so it largely measures size under another name, and Martin Shepperd published that critique in 1988.
The standard defines reliability as the degree to which a system performs specified functions under specified conditions for a specified period of time. That describes a running system, and redundancy, health checks, capacity, and deployment practice decide most of it. The measure reads source code through static analysis. It does not run the system, and it does not run the system's own tests. No one has shown that the count predicts the behavior in the definition. The same gap applies to the other three characteristics, because each one is defined as an outcome and measured as a count of static patterns.
Five layers of the public-interest problem
Software safety and AI safety cannot be assured until these five gaps are closed. None of them is closed today, and each one depends on the one above it.
Validated ground-truth measurement. A 2021 tertiary review covering 75 secondary studies drawn from 7,811 articles found the field far from consensus, with validity questions attached to the measures in common use and almost nothing known about predicting maintainability. Its authors note that frequent use is not evidence of correctness.
Verification a non-specialist can trust. The volume of code written by AI requires test automation that a programmer who is not a specialist can run. The automation also has to target the failure modes specific to the way AI assistants write code, and nobody has established what those are under controlled conditions. Anecdote stands in for evidence.
A discipline a team can adopt without changing language or retraining. Tools that eliminate categories of defect by construction have existed for decades. SPARK, Coq, Lean, and dependent type systems all do it, and each one requires a different language, a new type system, or substantial retraining, which is why they have remained relatively niche solutions. Nothing does it across a full application, in the languages and frameworks a team already has. The tools that come closest are per-language libraries whose rules each team writes for itself, with no shared specification and no conformance suite. One community has done it for one layer of one kind of application. React front ends settled on a way of building where information moves in one direction and is never altered in place, and in the Foundation's survey their code met the structural measure far more often than the rest of the code examined.
Pristine reference material. Code written by AI is only as good as the codebases it was trained and prompted from. Reference codebases free of structural anti-patterns are a precondition for trustworthy AI-assisted work, and nobody is producing them systematically.
An account of the mechanisms behind prompting success. Prompting is one of the most active areas in AI research, and many strategies have been shown to work in particular settings. Why they work is not understood. Steering a model toward better code requires knowing which properties of a training corpus produce which capabilities, and that question is open.
Each layer has the same four gaps under it: no research establishing the ground truth, no consensus standard built on that evidence, no specification whose measures have been checked against what happens after deployment, and no credential attesting that a practitioner can apply any of it.
Scope. Current work is on safety-relevant and security-relevant software, including software where code written by AI introduces structural risk to public welfare. The Foundation does not claim its findings generalize past that domain, because construct validity has to be shown in one domain before it is claimed for another.
What the Foundation has not established
No one has validated the Slop Audit against deployment outcomes. Two questions are open: whether the audit measures the structural risk it claims to measure, and whether its scores predict what happens after a system ships. The studies that would settle them are registered and awaiting funding.
The 200-repository measurement covers one indicator out of the 20 the audit computes mechanically, and it ran on public open-source code. It is not a claim about enterprise codebases in general.
One layer of the audit depends on trained assessors rather than on computation, so it has the question any judged assessment has: whether two assessors reach the same score. The calibration protocols are in preparation.
The audit maps to ISO/IEC 25010 and not yet to ISO/IEC 5055. That mapping is on the roadmap.
Four programs
Inside its scoped domain, the Foundation closes the stack of gaps above through four programs that feed one another.
Scientific research. Registered empirical research deposited on the Open Science Framework with persistent identifiers, released through peer-reviewed publication and open-access repositories. Two lines run in parallel: correctness research and language and thought.
Public education. Open curriculum, public events, invited talks, and explanatory material written for readers without a technical background, in service of the public's right to understand how the software and AI systems mediating their lives work and where those systems stop working.
Open technical standards. Specifications in the manner of RFC-class public technical standards, which software can be written to and assessed against, released under terms that let any implementer write conforming software without permission or fee. The Slop Audit and the Honest Framework are the two published so far.
Certification. A Certified Honest Practitioner credential awarded on measured competence, open to any programmer whatever their institution, geography, or prior credentials. Implementations of the standards can be certified as conforming to them.
Who decides what goes into the code
Maintainers and working groups decide what goes into the code. The Foundation does not. It conducts the research, delivers the educational programs, acts as custodian of the standards, and runs the certification. It also protects all four against capture by commercial interests, and the Governance page describes the structure built for that.
Where things stand
The Foundation was incorporated in Missouri on May 5, 2026, as a public-benefit nonprofit corporation under RSMo Chapter 355. It operates under fiscal sponsorship by the Foundation Source Charitable Fund, a 501(c)(3) public charity, confirmed and operational since May 12, 2026. Federal 501(c)(3) recognition is pending, with IRS Form 1023 in preparation. The Open Honest Trust is in parallel formation.
The Slop Audit methodology covers 18 compliance-mapped dimensions. The Honest specification is structurally complete and stable, with a formal conformance suite of roughly 50 laws across seven modules. The Python reference implementation is in active development, and implementations in JavaScript, Ruby, and other languages will follow.
Comparable organizations. This mission profile is shared by many established 501(c)(3) public charities working in technical standards, professional credentialing, and applied research, among them the Internet Society, which hosts the IETF, the Institute of Electrical and Electronics Engineers, the Massachusetts Institute of Technology, which hosts the W3C, ASTM International, ANSI-affiliated bodies, the Project Management Institute, ISACA, ISC², and the credentialing programs of the American Bar Association sections.
Lobbying and political activity. The Foundation does not and will not engage in any substantial lobbying activity within the meaning of Section 501(c)(3), and does not and will not participate or intervene in any political campaign for or against a candidate for public office.
Sources. Datacurve, "DeepSWE: Measuring frontier coding agents on original, long-horizon engineering tasks," 2026. ISO/IEC 5055:2021, Automated source code quality measures, and the CISQ reliability measure description. Tempero and others, "Qualities of Quality: A Tertiary Review of Software Quality Measurement Research," 2021. Shepperd, M., "A critique of cyclomatic complexity as a software metric," 1988.