FPF: A Declarative Pattern Language for Engineering Work Shared Between Humans and AI Agents

The Problem FPF Targets: Claims That Blur Together

Engineering arguments fail in a specific way. A statement about what a system is, a claim about what it does, a piece of evidence, a permission, and a decision all get compressed into one sentence in a meeting or one paragraph in a chat with an AI agent. FPF exists to keep those categories separate. Its README frames the two intended uses as AI-native FPF-driven engineering work, where an agent retrieves relevant patterns and exposes missing evidence or authority, and the description and engineering of mixed human-AI work, where people use the same language to state which System is being changed, which Method is proposed, which Work was performed, what is permitted, who holds decision authority, and what would reopen a decision.

The stated audience is the engineer-manager: people who identify as engineers but spend much of the day coordinating specialists, negotiating interfaces, organizing reviews, comparing trade-offs and allocating work among people, tools, robots and AI. The README is explicit that this describes Work, not a corporate job title. FPF is not aimed at a team that only wants a ticket tracker. It is aimed at someone who keeps losing the thread of which claim is which across a long project, and who wants an AI agent to hold that thread without inventing the missing parts.

How the Pattern Corpus and Its Retrieval Model Fit Together

The mechanism is retrieval against declared situations and questions, not execution of a process. The README states that FPF Core contains more than 300 interlinked transdisciplinary patterns and that reading the whole corpus is not a prerequisite and is rarely the best human entry mode. Instead, a capable AI agent acts as a high-bandwidth reader: it searches the corpus, inspects a small set of plausible patterns, quotes exact source passages, and translates the distinctions into the engineer's working language.

The selection key is the pattern's own declared Situation and Question. You start from the current working situation and the question that is current now, then inspect the pattern whose declared Situation and Question match that difficulty, and use its distinctions, constraints, checks, result and stop or reopen conditions to produce the smallest useful result, or an honest blocker. Two things follow from this design. First, pattern numbers, file order, table-of-contents order and example order carry no project sequence, and the README says so directly: a real dependency belongs to the concrete results and Work under consideration, not to a universal process imposed by the language. Second, the useful next move can legitimately be a clarified question, an identified System, an evidence request, a decision record, or an explicit stop because a necessary basis is missing.

The repository also splits the corpus three ways. FPF Core is the transdisciplinary language. The Engineering DPF Suite holds published and planned FPF-grounded domain pattern languages for engineering, operation, maintenance, organizational change, decision support and human development, plus a Suite Reference for questions that draw on several DPFs. A separate Narrativization and Narrative Studies DPF covers turning selected source structure into a followable narrative while preserving recoverability, evidence limits, agency boundaries and viewpoint choices. The split matters operationally: an agent pointed at Core alone will not have the domain patterns, and an agent pointed at a DPF alone will not have the base vocabulary.

Getting an Agent Connected: MCP and the Files You Point It At

The README lists five entry points. FPF Core Specification lives at FPF-Spec.md in the repository. The Engineering DPF Suite is a directory named Engineering DPF Suite. The narrativization framework is a single file, Narrativization-and-Narrative-Studies-Principles-Framework.md. There is a browsable Core reference at https://fpf.sh/ and a documented way to connect an AI agent to FPF Core through MCP at https://mcp.fpf.sh/.

The practical setup implied by the material is: give the agent the Core specification as an explicit, inspectable reference, and add the relevant DPF for the domain in question. The README's framing is that this replaces improvising from generic model priors with a maintained, plural account of current engineering thought, so the agent can show which patterns and sources it used and separate a source-grounded recommendation from plausible but unsupported advice. The MCP endpoint is the only mechanism the README names for wiring an agent in directly; the repository does not document a CLI, a server command or a config file for local installation, and no releases were retrieved, so there is no version tag to pin against. If you need a pinned dependency, that absence is the first thing to resolve.

One constraint is stated as a rule rather than a suggestion: an AI-produced statement is not automatically a fact, evidence, permission, commitment or decision. Each such relation must be established by its own basis. Any setup that treats agent output as an approved decision record has already left the framework.

The Division of Labour Is the Actual Design Decision

FPF assigns the corpus and the situation to different parties. The engineer supplies 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 keeps those claims distinct rather than silently inventing them. The README calls the engineer's contribution what the corpus cannot supply.

This is a sharper boundary than it first appears. It means FPF has no opinion about your system's behaviour, and it cannot verify anything about the physical or software artifact you are changing. It can only help you keep the description of that artifact, and the claims made about it, internally consistent and traceable to sources. Teams that expect the framework to produce engineering answers will be disappointed. Teams that already have the answers and lose them between meetings are the ones the design fits.

The plural framing is deliberate too. The README describes FPF as a maintained, plural account of current engineering thought rather than a single correct method, and the domain frameworks are described as published and planned, which means the Suite is not a finished set. A question that falls outside the published DPFs has to be answered from Core vocabulary plus the Suite Reference, or not at all.

Where FPF Is the Wrong Tool

The README rules out three uses by name: FPF is not an agent framework, not an agent runtime, and not a software-coding methodology. If you want orchestration, tool calling, memory or execution scaffolding for agents, this repository does not provide it. If you want a coding process with steps and gates, the declarative design is explicitly against that: the language does not prescribe a project sequence, and file order is not process order.

The second limitation is maturity, and it comes from the project itself. The status line reads normative kernel and evolving ecosystem; eternal alpha, already used in working projects and development programs while continuing to change. There are no releases retrieved, so there is no changelog to read before upgrading and no version boundary between the specification you adopted and the one that exists six months later. For a normative document that other documents cite, that is a real cost: a pattern's declared Situation and Question can be revised underneath an agent that has cached or quoted it.

The third limitation is the entry mode. The corpus is large enough that the README treats human full reading as rarely the best path, which means the quality of your results depends on the retrieval step and on the agent's willingness to quote exact passages instead of paraphrasing. A team without a capable agent, or with one that summarizes loosely, gets a vocabulary list rather than a working language. And because the framework is transdisciplinary by design, spanning manufacturing, construction, mechanical and electrical engineering, energy, robotics, laboratories, healthcare technology, education and software-intensive Systems, the Core vocabulary is abstract on purpose. A narrow domain team may find the abstractions heavier than their problem warrants.

Alternatives and the Difference That Matters

The closest familiar comparison is an architecture decision record practice, where each decision is one dated file with context, options and outcome. ADRs capture decisions after the fact in a lightweight, per-project format. FPF instead supplies a shared vocabulary that spans Systems, Methods, Work, evidence, authority and reopening conditions, and it is meant to be queried by an agent at the moment a question is current rather than written up once. The trade is real: ADRs need no corpus and no retrieval, while FPF needs both, and ADRs give you a stable file format where FPF gives you a moving specification.

A second comparison is a requirements or modeling notation such as SysML, which gives you a diagram and a metamodel for the system being built. FPF does not model the system; it models the conversation about the system, including who is permitted to decide and what evidence supports a claim. If your problem is that the model and the artifact have drifted apart, a modeling notation addresses it. If your problem is that nobody can tell which of five statements in a thread is a decision, FPF addresses that.

A third is simply a well-written internal style guide plus a capable agent. That combination is cheaper and needs no new vocabulary, but it has no declared Situation and Question per entry, no stop or reopen conditions, and no way for the agent to show which maintained source it drew on. FPF's contribution is the structure of the entries and the traceability of the retrieval, not the existence of guidance.

Licence, Forking and the Cost of Keeping Up

Original framework content is licensed CC BY 4.0, and the README notes that third-party material retains its own terms. CC BY 4.0 permits sharing and adaptation with attribution, which matters for a document meant to be quoted inside an agent's answers and copied into project documentation. The practical implication is that attribution is the obligation to plan for, not a permission request. This is a description of the licence text, not legal advice; if you are embedding the corpus in a product, read the licence and the third-party notices yourself.

The maintenance cost sits in the corpus rather than in code. There is nothing to compile and no dependency graph to update, but the specification is described as continuing to change, and the Engineering DPF Suite includes planned frameworks alongside published ones. A team that quotes patterns inside decision records inherits the job of rechecking those quotations when the source moves. The README's own answer to this is the retrieval model: keep the corpus as the reference and let the agent quote exact passages at the time of use, rather than copying pattern text into your own documents where it will silently age. That is a workflow decision you make before adoption, not after.

Editorial conclusion

Adopt FPF when your problem is a disagreement about what is being discussed (which System, which claim, which evidence, which decision) and you have an engineer-manager willing to supply the situation, constraints and authority the corpus cannot. Do not adopt it as a coding methodology, an agent runtime, or a substitute for a requirements tool: the README states plainly that it is none of those, and the repository has no releases to pin. Verify first whether the specific pattern you need is normative or still moving, since the project describes itself as an eternal alpha, and check the MCP endpoint at mcp.fpf.sh before wiring an agent to it.

Official sources

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