The Ora Knowledge Foundation is an initiative in formation. It is not incorporated and is not accepting donations. Ora already publishes framework-related material in its public catalog, but the Foundation library described here is a proposal: no Foundation contribution intake, specification standard, expert review, recognition, update, or distribution system currently operates.
What the framework library is
Frameworks are the operational interface between Ora’s underlying capability and applied use. Without frameworks, cognitive automation is raw capability that most people cannot deploy effectively. With frameworks, the capability becomes usable for specific tasks that matter.
A framework is a structured specification: input format, processing steps, decision points, output format. It is written in natural language because the source code of cognitive work is the cognitive specification itself, not the code that executes it. Any Ora user can invoke a framework against a problem the framework addresses; the harness runs the framework against the user’s input, produces structured output, and saves the result to the user’s vault.
The proposed framework library would collect these specifications in a freely distributed, version-controlled catalog. Existing Ora framework materials can already be read and reused under their stated public-domain terms. A future Foundation could steward a reference collection that anyone could fork, modify, or use as the basis for an independent collection; it does not maintain such a contribution-based library today.
Launch-critical, not long-term
The framework library is conceived as launch-critical rather than a distant, long-term program. A knowledge library could grow gradually over decades, but any future Foundation launch would need a usable framework catalog because the disruption itself could reduce framework-development capacity. Whatever is not available when people need it may be difficult to author from scratch under economic stress.
The proposed launch list reflects this urgency. It covers high-impact uses where commercial chokepoints have extracted excess value and where free public-domain alternatives could give affected populations tools their employers and convenience-market vendors may not provide.
Tax preparation. A tax-filing framework is the paradigm case. No such Ora or Foundation framework is currently published. If one were completed and validated against current tax law and forms, a free framework could guide households through filing. Possible extensions could include common federal and state returns, small-business filings, and supporting schedules.
Public benefits applications. An IHSS California framework is proposed as the complexity demonstration. Such frameworks could narrow the gap between need and access for low-income populations. Possible extensions include veterans benefits, Social Security, immigration applications, SNAP, housing assistance, and unemployment.
Basic legal documents. Future frameworks could help users prepare routine wills, contracts, or leases while clearly identifying when professional legal review is necessary.
Basic medical information synthesis. Synthesis only, not advice. A future framework could help users organize what they know, what they have read, and what they want to ask before a clinical conversation. It would not diagnose or replace a clinician.
Basic financial planning. Future frameworks could address household budgeting, debt management, and retirement planning for people priced out of conventional advisory services.
Basic business operations. Future frameworks could help individuals and small partnerships prepare business plans, operating agreements, or basic bookkeeping structures that historically required hiring out.
These categories are not exhaustive. They describe a possible baseline. If a contribution system is built, domain experts in adjacent areas could propose frameworks as needs surface.
Chokepoint elimination as selection logic
Beyond enabling task completion, the proposed framework library could become one instrument for chokepoint elimination at the consumer-facing layer. Candidate frameworks would be selected because they address needs where commercial chokepoints have extracted excess value.
The proposed selection logic is principled rather than reactive. A future program would not target commercial actors that earn margins close to their delivered value. It would focus on chokepoints — situations where the gap between extracted and delivered value is wide enough to constitute rent extraction at scale, sustained by structural advantages such as format lock-in, network effects, regulatory capture, or distribution control rather than ongoing innovation.
The TurboTax case is the cleanest example. Intuit charges hundreds of millions of US households roughly $50–$200 per year for the same work — completing a 1040 — that has the same shape every year and that the IRS already has software to validate. The cost of producing a framework that does the same work, on the user’s machine, with the user’s data staying private, with the framework freely distributed, is low. The price-to-cost ratio Intuit sustains is the chokepoint: it is held in place by Intuit’s lobbying against the IRS providing free direct filing, by Intuit’s distribution channels with retail tax preparers, by network effects in the professional preparer community. Once a free public-domain framework exists, the chokepoint dissolves. Intuit’s pricing has to come from value Intuit actually delivers, not from the absence of a free alternative.
The same logic would apply to the rest of the proposed list. Each candidate represents a possible chokepoint intervention: benefits-application help, routine legal documents, basic financial planning, or small-business operational documents. Whether a particular framework is appropriate would depend on validation, safeguards, and a truthful account of its limits.
The framework-library proposal is not anti-commercial. It does not target the commercial software industry generally. Its intended focus is the specific structural patterns where commercial actors extract rent rather than deliver corresponding value. The goal would be to dissolve those structures around tasks whose cost no longer justifies a commercial chokepoint.
Governance model
The proposed governance model draws on Apache, Wikipedia, and Creative Commons. A future Foundation could publish specifications for input and output formats, version control, documentation, and testing. Contributors could then develop frameworks against those specifications, with multiple approaches to the same task allowed to coexist. These specifications and contribution channels have not been built.
The Foundation’s proposed role would be specification authorship and library infrastructure, not authorial control over individual frameworks. This is intended to distribute cultural power that might otherwise concentrate in staff. Forks, modifications, and independent collections would remain welcome.
This is the same governance pattern that has worked for Apache projects for two and a half decades, for Wikipedia article editing for two decades, for Creative Commons license stewardship for nearly two decades. It is well-understood, has a long track record, does not require unusual structures, and produces durable corpora that survive the organizations that initially seeded them.
Publication would make the contribution model legible. A future contributor could read the specification before proposing a framework and understand what a submission would need to contain. In that model, the specification would serve as the contract. No Foundation submission process currently accepts or reviews contributions.
Contribution flow
The proposed contribution flow adapts standard open-source patterns for natural-language artifacts rather than code:
-
A contributor would identify a framework need or develop a prototype. The need might come from the contributor’s own work or from a future published backlog.
-
The contributor would submit the framework against a published specification covering metadata, body sections, documentation, and meaningful edge-case tests.
-
Domain experts and active contributors would review the framework against that specification: whether it produces reliable output for the stated use case and documents its limitations clearly.
-
If accepted, the framework would enter the library with attribution and version-control history. The contributor’s authorship would be preserved, and the framework would be dedicated to the public domain with the contributor’s informed agreement.
-
Later revisions would follow the same flow with prior versions preserved as part of the corpus.
The intended contribution barrier is domain expertise, not technical skill. A legal aid attorney could contribute a framework for benefits applications because she knows what the form requires; she would not need to write code. Natural language is the source code. If implemented, this could open contribution to people conventional open source often excludes.
Relationship to Ora and to external maintenance
Ora already exposes its own available framework-related material. The broader Foundation library and automatic update path described here do not exist. If built, a Foundation-stewarded collection could become one in-system source of capabilities, while users could also install frameworks from forks or independent collections.
For domain-specific frameworks with high maintenance burdens — government forms that change annually, for example — the proposed Foundation could distribute methodology and worked examples rather than promise indefinite maintenance of every form. Ongoing maintenance would be better placed with organizations that already have the relevant expertise, such as legal-aid or benefits-navigation groups. No such maintenance or distribution partnerships currently exist.
The implication is that a future Foundation library would need natural boundaries. It could steward reference examples for selected categories without becoming the maintainer of every form in every jurisdiction.
What the framework library is not
It is not intended as a list of useful tools. If built, it would be an operational interface for cognitive automation at the consumer-facing layer and a substrate for the proposed chokepoint work.
It would not be an exclusive collection. Multiple frameworks for the same task could coexist; forks and alternatives would be welcome; a Foundation-stewarded collection would be one option among many.
It is not the same thing as the proposed knowledge library. The knowledge library would be a corpus of facts, references, and atomic claims for retrieval-augmented generation; the framework library would be a corpus of cognitive specifications that frame how a harness uses a model. If both were built, they could compose: a framework run could request the kinds of context it needs from the knowledge library.
It is not conceived as a children’s product, developer tool, research infrastructure, or conventional productivity service. It would be public cognitive infrastructure, with users deciding what work to perform through it.