FPF: 300 patterns, a declared non-scope, and a keyless reader for agents

FPF states what it is not, in three specific denials

The clearest paragraph in the project is the negative one. FPF is not an agent framework, not an agent runtime, and not a software-coding methodology. It is a knowledge and reasoning framework.

That framing does real work, because the name invites all three misreadings. A pattern library that tells an agent what to retrieve sounds like a runtime. A vocabulary for how engineers should proceed sounds like a methodology. Neither is what is being offered.

The scope it claims instead is wide and deliberately cross-domain: manufacturing, construction, mechanical and electrical engineering, energy, robotics, laboratories, healthcare technology, education, embodied practice, software-intensive systems, and other fields. The unifying claim is that these all involve the same moves, and that the moves can be written down.

The status line is candid in the same register. It describes the publications as evolving and self-describes as an eternal alpha, already in use inside working projects and development programs while continuing to change. There are no GitHub releases, which is consistent with that framing rather than in tension with it.

The last push to the default branch is dated 2026-09-25, so the material is being revised even while it declines to be versioned.

More than 300 patterns, and reading them all is explicitly not the entry mode

FPF Core holds more than three hundred interlinked transdisciplinary patterns. The project then says something that is unusual for a pattern catalogue to say: reading and remembering the entire corpus is not a prerequisite for using it, and is rarely the best entry mode for a person.

Instead the proposed division of labour puts the corpus in the agent's hands. A capable agent is described as a high-bandwidth reader of the pattern language, one that can search the corpus, inspect a small set of plausible patterns, quote exact source passages when needed, and translate the relevant distinctions into the engineer's own working language.

The stated benefit is not better recall. It is that an FPF-driven setup hands the agent explicit, inspectable references instead of letting it improvise from generic model priors. With those references in place the agent can follow a maintained account of current engineering thought, show which patterns and sources it used, and separate a source-grounded recommendation from advice that is merely plausible.

That last separation is the whole point of quoting source passages. A corpus you cannot cite produces the same ungrounded output as no corpus, only with more steps in front of it.

An AI-produced statement is not automatically a fact, evidence or a permission

The page draws an explicit line around what counts as what, and it does so by enumeration. An AI-produced statement is not automatically a fact, not evidence, not permission, not a commitment, and not a decision. Each of those relations has to be established by its own basis.

The phrase AI-native does not mean AI-only. It is defined as the ability to deliberately reconsider the architecture of the work around the different capabilities and limitations of humans, AI agents, tools and other systems.

The counterweight is a list of what the corpus cannot supply, and it is assigned to the engineer: the actual situation, domain knowledge, observations, constraints, stakes, local history, access to the engineered system, and any real assignment, permission, responsibility or authority. The agent's contribution here is described as keeping those claims distinct rather than silently inventing them.

So the framework's central move is a typing discipline rather than a method. A number produced by an agent and a number backed by a measurement occupy different categories, and the gap between them is where the unreviewed work accumulates. That is a claim about failure modes rather than about productivity, and it is the part of the project that transfers to work that has nothing to do with AI at all.

engineer-manager names Work, not a corporate job title

The project introduces a coined occupational term and then goes out of its way to prevent it from becoming a job title. An engineer-manager is defined as an engineer who identifies primarily as an engineer but spends much of their day doing substantive management work.

What that work consists of is enumerated: coordinating specialists and providers, negotiating architecture and interfaces, organizing reviews and working meetings, comparing alternatives and trade-offs, formulating strategies, making responsible decisions, preserving knowledge, and allocating work among people, tools, robots and AI.

The closing sentence is the constraint: the term describes work, not a corporate job title. That matters because the rest of the framework is built on the same distinction. Work is a first-class noun here, along with System and Method, and it is capitalised throughout as a defined term rather than used as a synonym for labour.

The stated purpose of the term is to give AI agents and this particular kind of engineer a shared language. The two uses offered are FPF-driven engineering work where an agent retrieves and compares patterns, and the description and engineering of mixed human-AI work where both sides name which system is being changed, which method is proposed, and who holds decision authority.

A keyless MCP endpoint, and a status page that carries the revision

The corpus is published as files in a repository, but the intended reading path is a website. It offers a browser view for reading publication contents and source passages, a search over publication texts by words, quoted phrases or pattern identifiers, and an MCP server for agents.

The remote endpoint is given explicitly as a Streamable HTTP address, and public reading requires no API key. That is the single most consequential operational detail on the page. An agent can be pointed at the corpus without provisioning a credential, which removes the most common reason a knowledge base stays unused.

Two supporting pages exist because of the same concern. A status page records the revision currently available through the website and the MCP server, which is how a reader tells whether what they are reading matches what is in the repository. And an in-use page is labelled as an editorial page on the website, separate from the Library distribution, which keeps user claims out of the distribution itself.

Read-only is also stated, twice, once as the description of the browser and MCP access and again in the phrasing about connecting an agent. Nothing in what is written down describes a write path.

USING-FPF.md is a required first read, and it carries an exception

Before selecting any framework guidance, the project says to read and apply a document called USING-FPF.md. The stated scope of that instruction is broad: project work, framework development, review and coordination. It is described as explaining how to find and read relevant content in the publications available to the reader, including the case where an interface cannot retrieve a large file.

Then comes the instruction aimed at agents. When an AI agent is helping, the requirement and the location of the instruction should be put into the project's AGENTS.md or equivalent, so the agent is told to follow it rather than having to discover it.

What is notable is the carve-out. The text says that if a reading test explicitly limits its reader to an isolated excerpt, only the materials supplied for that test should be used, and USING-FPF.md should not be added unless the test includes it. That is a guard against an agent pulling in a required-reading document that the test deliberately withheld.

Practically, it means the repository expects to be adopted by copying an instruction into your own agent configuration, not by being read once by a person. That is a heavier commitment than cloning a package, and it is the mechanism by which the pattern-selection rule below actually reaches the agent.

Readme.md is the filename, and one framework ships as a file while two ship as directories

The repository has eight top-level entries. Two are directories, and they carry spaces in their names: a Foundational Thinking DPF Suite directory and an Engineering DPF Suite directory. The links to them in the page are percent-encoded, which is what a space in a path looks like when it reaches a URL.

Three documents sit at the top alongside them: the core specification, a using guide, and a single file for a Narrativization and Narrative Studies principles framework. So one domain framework ships as a bare markdown file while two ship as directories of material.

There is also a licensing document next to the license file, which is consistent with the stated terms: CC BY 4.0 for original framework content, with third-party material retaining its own terms. The repository metadata reports CC BY 4.0, which is a single identifier for what is actually a two-tier grant.

And the readme itself is named Readme.md rather than README.md. On a case-insensitive filesystem nothing breaks, and the page is reachable at its root, but any tooling that looks for the conventional filename, including some clone and viewer scripts, will not find it.

The tree also contains nothing executable. With no detected primary language and no build step, this is a document distribution rather than a package, which is consistent with how the project describes itself as a collection of publications.

Selection starts from the question in front of you, and the page ends mid-sentence

The final section sets out the operating rule. FPF and its domain frameworks are declarative pattern languages rather than a prescribed process. You start from the current working situation and the question that is current now. You inspect the pattern whose declared situation and question match that difficulty. You then use that pattern's distinctions, constraints, checks, result, and its stop or reopen conditions, to produce the smallest useful result, or an honest blocker.

Three properties of that rule are worth naming. It is keyed to a question rather than to a stage, which means there is no order to follow. It ends in a stop or reopen condition rather than a completion criterion. And it explicitly permits an honest blocker as an output, which is unusual in guidance aimed at getting work done.

The page then breaks off. The last line on the visible page reads Pattern numbers, file order, and stops there, mid-sentence, before the explanation of what pattern numbers and file order are or are not meant to convey.

That gap is in the section that most needs the detail. Everything above tells you to select a pattern by its declared situation and question, and the fragment that would have explained how patterns are numbered and ordered is the part that is not written down here. The links to the core specification and the suite references are the places to look.

Editorial conclusion

FPF is worth reading if you want a written, inspectable vocabulary for engineering reasoning that an agent can cite rather than improvise, and the parts that make it usable are the refusals: a declared non-scope, a pattern-selection rule keyed to the question in front of you, and the insistence that an AI statement is not evidence until a basis establishes it. Two practical notes before you commit. The corpus is deliberately too large to read end to end, so access matters more than ownership, and the site exposes a read-only MCP endpoint that needs no key. And the licence is CC BY 4.0 for original content with third-party material keeping its own terms, so read the separate licensing document before reusing anything.

Frequently asked questions

Official sources

1. ailev/FPF on GitHub
2. Issues
3. License: CC-BY-4.0
4. README