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 framework library is the curated collection of these specifications. Freely distributed. Version-controlled. Open to contribution. The Foundation maintains the canonical library; anyone can fork it, modify frameworks, develop alternatives, or build entirely new collections.

Launch-critical, not long-term

The framework library is launch-critical, not long-term. The knowledge library can grow gradually over decades. The framework library has to exist at launch in some usable form because the disruption itself disrupts framework-development capacity. Whatever isn’t in the library at launch may not exist when people need it most, because the populations facing the steepest displacement will not have the institutional bandwidth to author frameworks from scratch under economic stress.

The launch list reflects this urgency. It covers the categories of high-impact, high-displacement-relevance use cases where commercial chokepoints have extracted excess value and where free public-domain alternatives compound with the displacement to give affected populations tools their employers and the convenience-market vendors will not provide.

Tax preparation. 1040-EZ as the paradigm case, in development. The TurboTax monopoly Intuit has lobbied to preserve for decades dissolves when a free framework can guide any household through filing. Natural extensions: 1040 long form, common state returns, small-business filings, the schedules and supporting forms.

Public benefits applications. IHSS California as the complexity demonstration, in development. Closes the gap between need and access for low-income populations. Natural extensions: veterans benefits, Social Security, immigration applications, SNAP, housing assistance, unemployment.

Basic legal documents. Wills, contracts, leases. Routine legal work that should not require paying gatekeepers but currently does because the cost of having a paralegal review the document is the friction that protects the chokepoint.

Basic medical information synthesis. Synthesis only, not advice. Helps users prepare for clinical conversations by organizing what they know about their condition, what they have read, what they want to ask, what the standard treatment options are. The framework does not diagnose; it makes the user a more informed participant in clinical conversations they will still have with clinicians.

Basic financial planning. Household-level budgeting, debt management, retirement planning. Dissolves the advisory-fee structure that prices out moderate-income households from the same financial planning that high-net-worth households take for granted.

Basic business operations. Small enterprises. Business plans, operating agreements, basic bookkeeping logic. Frameworks that let an individual or a small partnership produce the operational artifacts that historically required hiring out.

These are not exhaustive. They are the launch-critical baseline. Domain experts in adjacent areas can contribute frameworks that fill in around the baseline as needs surface.

Chokepoint elimination as selection logic

Beyond enabling task completion, the framework library is the Foundation’s primary instrument for chokepoint elimination at the consumer-facing layer. Each launch-critical framework is selected because it addresses an underlying need where commercial chokepoints have extracted excess value.

The selection logic is principled rather than reactive. The Foundation does not target commercial actors that earn margins close to their delivered value; competitive markets where vendors compete on value are not the Foundation’s concern. The Foundation targets chokepoints — situations where the gap between extracted and delivered value is wide enough to constitute rent extraction at scale, sustained by structural advantages (format lock-in, network effects, regulatory capture, distribution control) rather than by 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 applies to the rest of the launch list. Each framework is a specific chokepoint dissolution: the chokepoint where households pay for benefits-application help they could do themselves with the right framework; the chokepoint where households pay paralegals for routine legal documents that have stable templates; the chokepoint where moderate-income households are priced out of basic financial planning by hourly advisor fees calibrated to high-net-worth clients; the chokepoint where small businesses pay outsized fees for operational documents that have well-understood formats.

The framework library is not anti-commercial. It does not target the commercial software industry generally. It targets the specific structural patterns where commercial actors are extracting rent rather than delivering value. The Foundation is not picking fights with software vendors who earn their margins; it is dissolving rent-extraction structures around tasks the cost of producing software no longer justifies as commercial work.

Governance model

Framework library governance follows the Apache / Wikipedia / Creative Commons pattern. The Foundation publishes specifications for what frameworks should look like — input format conventions, output format conventions, version-control conventions, documentation requirements, testing requirements. Contributors develop frameworks that meet the specifications. Frameworks meeting the specifications enter the library. Multiple frameworks for the same task can coexist; the library is not exclusive.

The Foundation’s role is specification authorship and library infrastructure, not authorial control over individual frameworks. This distributes the cultural power that would otherwise concentrate in Foundation staff. The Foundation does not gatekeep alternative frameworks: forks, modifications, and entirely independent collections are welcomed and expected.

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.

The Foundation publishes specifications because publication is what makes the contribution model legible. A contributor who wants to add a framework to the library knows what the framework has to look like by reading the specification. The contributor produces a framework that meets the specification. The specification is the contract.

Contribution flow

The contribution flow follows standard open-source patterns adapted for natural-language artifacts rather than code:

  1. A contributor identifies a framework need or develops a framework prototype. The need might come from the contributor’s own work — a domain where the contributor knows what good looks like and where no framework currently exists. Or it might come from a stated gap in the Foundation’s framework backlog, where a need has been identified but no framework has been authored.

  2. The contributor publishes the framework against the Foundation’s specification standard. The standard covers what the framework’s frontmatter should specify, what the framework’s body sections should cover, what the framework’s documentation should include, what test cases should exercise the framework’s edge cases.

  3. The framework is reviewed by domain experts and active library contributors against the specification — does it meet the specification, does it produce reliable output for the stated use case, does it document its limitations clearly. The review is not gatekeeping in the conventional open-source sense; it is checking that the framework meets the published specification.

  4. If accepted, the framework enters the library with attribution and version-control history. The contributor’s authorship is preserved; the framework is dedicated to the public domain.

  5. Subsequent revisions follow the same flow, with prior versions preserved. A framework that gets revised does not erase its prior version; the version history is part of the corpus.

The contribution barrier is domain expertise, not technical skill. A legal aid attorney can contribute a framework for benefits applications because she knows what the form requires; she does not need to write code. Natural language is the source code. This inverts the traditional open-source contribution model in a way that opens contribution to populations conventional open source largely excludes.

Relationship to Ora and to external maintenance

The framework library is distributed with Ora and operates as the in-system menu of available capabilities. New frameworks added to the Foundation’s library propagate to user installations through standard update mechanisms. Users can also install frameworks from forks or independent collections; the Foundation’s library is one option, not the only one.

For domain-specific frameworks with high maintenance burden — government forms that change annually, regulations that update jurisdiction by jurisdiction — the Foundation distributes the methodology and worked examples rather than maintaining the specific form libraries indefinitely. The maintenance work is properly placed with organizations that already have the domain expertise: legal aid organizations for legal frameworks, benefits navigation nonprofits for benefits frameworks, social services advocacy groups for social services frameworks. The Foundation provides the architecture; domain experts provide the ongoing maintenance through their own institutional channels. This is a distribution strategy rather than a separate organization.

The implication is that the Foundation’s framework library has natural boundaries. It maintains canonical reference frameworks for each launch-critical category. It does not become the maintainer of every form in every jurisdiction; that work scales to the institutions whose mission already includes it.

What the framework library is not

It is not a list of useful tools. It is the operational interface for cognitive automation at the consumer-facing layer, and the substrate against which the chokepoint-elimination work runs.

It is not an exclusive collection. Multiple frameworks for the same task can coexist; forks and alternatives are welcomed; the canonical library is one option among many.

It is not the same thing as the knowledge library. The knowledge library is the corpus of facts, references, and atomic claims that retrieval-augmented generation operates against. The framework library is the corpus of cognitive specifications that frame how the harness uses the model against any given problem. The two libraries compose: a framework run produces output that gets contextualized against the knowledge library; the knowledge library is searched against the framework’s specification of what kind of context the work needs.

It is not a children’s product, a developer tool, a research infrastructure, or a productivity service in any conventional sense. It is the cognitive infrastructure the Foundation stewards, and the cognitive automation that runs against it is what the user does with the architecture.

The summary