AI-native declarative pattern languages for engineering work. FPF gives engineers and AI agents a shared, precise language for Systems, Methods, architecture, Work, evidence, verification, decisions, improvement, and communication.
FPF Core Specification · Engineering DPF Suite · Narrativization DPF · Browsable FPF Core Reference · Connect an AI agent to FPF Core through MCP
Author: Anatoly Levenchuk, with AI-agent assistance
Status: normative kernel and evolving ecosystem; eternal alpha—already used in working projects and development programs while continuing to change.
FPF is no longer only one Core specification. This repository contains the transdisciplinary FPF Core, the Engineering DPF Suite, and a separate Narrativization and Narrative Studies DPF. Together they form an ecosystem of FPF-grounded pattern languages for difficult work across engineering, research, management, education, and other domains.
FPF is designed for two complementary uses:
- AI-native, FPF-driven engineering work. An AI agent can retrieve relevant patterns, compare their declared situations and questions, explain them in plain technical language, expose missing evidence or authority, and help produce the next useful result.
- Description and engineering of mixed human–AI work. People can use the same language to describe which System is being changed, which Method is proposed, which Work is actually performed, which capabilities are available, what is assigned or permitted, who has decision authority, what evidence supports a claim, and what would reopen a decision.
FPF is not an agent framework, an agent runtime, or a software-coding methodology. It is a knowledge and reasoning framework that can guide work in manufacturing, construction, mechanical and electrical engineering, energy, robotics, laboratories, healthcare technology, education, embodied practice, software-intensive Systems, and other fields.
The FPF Core contains more than 300 interlinked transdisciplinary patterns. Reading and remembering the entire corpus is not a prerequisite for using it—and is rarely the best human entry mode. A capable AI agent can serve as a high-bandwidth reader of the pattern language: 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 working language.
Instead of asking an agent to improvise from generic model priors, an FPF-driven setup gives it FPF Core and the relevant DPFs as explicit, inspectable references. The agent can then follow a maintained, plural account of current engineering thought, show which patterns and sources it used, and separate a source-grounded recommendation from plausible but unsupported advice.
The engineer supplies what the corpus cannot supply: 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 helps keep these claims distinct rather than silently inventing them.
This division of Work makes FPF useful as a common language between AI agents and engineer–managers: engineers who identify primarily as engineers but spend much of their day doing substantive management Work. They coordinate specialists and providers, negotiate architecture and interfaces, organize reviews and working meetings, compare alternatives and trade-offs, formulate strategies, make responsible decisions, preserve knowledge, and allocate Work among people, tools, robots, and AI. The term describes Work, not a corporate job title.
AI-native does not mean AI-only. It means that the architecture of the Work can be deliberately reconsidered around the different capabilities and limitations of humans, AI agents, tools, and other Systems. An AI-produced statement is not automatically a fact, evidence, permission, commitment, or decision. Each such relation must be established by its own basis.
FPF and its DPFs are declarative pattern languages. Start from the current working situation and the question that is current now. Inspect the pattern whose declared Situation and Question match that difficulty. Use its distinctions, constraints, checks, result, and stop or reopen conditions to produce the smallest useful result—or an honest blocker.
Pattern numbers, file order, table-of-contents order, and the order in which examples are presented do not prescribe a project sequence. Several kinds of engineering Work may overlap. A real dependency still matters when one result cannot be used before another exists, but that dependency belongs to the concrete results and Work under consideration, not to a universal process imposed by the pattern language.
An AI agent can therefore help choose the next justified move without pretending that the entire project follows one fixed sequence. The useful move may be a clarified question, an identified System, an architecture comparison, an evidence request, a decision record, a changed Method, a bounded Work plan, a source-grounded explanation, or an explicit stop because a necessary basis is missing.
| Publication | What it contributes | Typical working questions |
|---|---|---|
| FPF Core Conceptual Specification | A transdisciplinary language for entities and relations, Systems, Methods, Work, descriptions, claims, evidence, decisions, architecture, quality, improvement, cultural evolution, publication, and precise language. | What exactly are we discussing? What claim is being made? Which relation obtains? What may the evidence support? Which decision is current? What Work actually occurred? |
| Engineering DPF Suite | Published and planned FPF-grounded domain pattern languages for engineering, operation, maintenance, organizational change, decision support, human development, and other practices, plus a Suite Reference for questions that draw on several DPFs. | Which System and use are current? Which architecture, interface, configuration, obtaining arrangement, Method, capability, verification result, or change is needed? |
| Narrativization and Narrative Studies DPF | Patterns for turning selected source structure into a followable narrative while preserving recoverability, evidence limits, agency boundaries, viewpoint choices, and source return. Includes human and automated narrativization. | What source structure must survive the rendering? What may be compressed or reordered? Did a fluent narrative invent causality, agency, certainty, permission, or authority? |
The list below covers the 16 published and planned DPFs in the current Suite plan. Links open the available texts; Planned publication marks a DPF selected for a later release.
| Domain pattern language | Publication status | What it covers or is planned to cover |
|---|---|---|
| Systems Engineering DPF | Published | project System focus; intended use; affected Systems; problem and System-family options; functional organization; architecture and interfaces; specialist contributions; build, buy, provider, reuse, AI, or hybrid arrangements; recursive realization; integration; platforms; configuration and effectivity; release evidence; source change; evolvability; overlapping Work; and engineering culture. |
| Method Engineering DPF | Published | Method identity; composition and architecture; descriptions and representations; support; trials; coherence; situational fit; transfer; practical worth; variants; introduction into practice; continuation; and change of a Method-engineering culture. |
| Music and Dance Practice Engineering DPF | Published | embodied capability; coordination; generation; performance; observation; recognition; learning and transmission; supporting arrangements; alternatives; local change; style development; and cultural continuation in Music and Dance practice. |
| Organization Change Engineering DPF | Published | organizational contributions, roles and assignments; authority and interfaces; capability allocation; comparison and realization of organizational changes; participation and adoption; culture; and the effects of change on actual Work. |
| Problem Structuring and Decision Support DPF | Published | problem formulations and participants; construction of alternatives and development opportunities; values, uncertainty and consequences; comparison; recommendations; and follow-up. Includes Development Direction Advising for people, organizations and other agents. |
| Operations Management DPF | Planned publication | continuing Work; modes and admission; cases, queues and flow; work in progress; constraints, capacity and commitments; resources and human conditions; exceptions; and improvement informed by operating evidence. |
| Maintenance Engineering DPF | Planned publication | maintenance policy; degradation and condition evidence; selection and delivery of interventions; verification of return to use; and learning from repeated maintenance Work. |
| Human Capability Development DPF | Planned publication | human capability needed for later Work; demand and capability profiles; target practice; development interventions; assessment, transfer and retention; providers and support; development portfolios; and qualification. |
| Strategy DPF | Planned publication | direction under uncertainty; option families and scenarios; capabilities, dependencies and initiatives; investments and business models; commitments; and decisions to revise, pivot, pause or stop. |
| Corporate Finance DPF | Planned publication | financing, liquidity and working capital; capital allocation and valuation; cost of capital and capital structure; financial exposure; and consequences for other organizational decisions. |
| Corporate Governance DPF | Planned publication | ownership and voting rights; board responsibilities; executive oversight; conflicts of interest and minority treatment; disclosure; audit, control and corporate accountability. |
| Engineering Asset Management DPF | Planned publication | value, risk, performance, cost and capacity across engineered assets and their supporting Systems; portfolio choices; renewal; and the choice of interventions over an asset's life. |
| Organization Administration DPF | Planned publication | organizational requests and cases; standard and exception paths; authorization, provision and access; records and retention; reconciliation; service interfaces; and revision of administrative arrangements. |
| Embodied Rhythmics DPF | Planned publication | rhythmic organization; rhythmic specifications and representations; enactment and comparison of variants; configuration of a performing whole; reference, phase, tempo and layers; and response, continuation and development. |
| Semantic Integration Engineering DPF | Planned publication | making separately governed contexts, semantic models, schemas, identities, claims, data and representations work together; mappings, provenance, quality, interfaces and change. Includes ontology and knowledge-graph engineering Methods. |
| Research Method Practice DPF | Planned publication | framing a research question from sources; comparing current and rival approaches; study and probe design; operationalization and sampling; records and provenance; analysis and criticism; reproducibility, replication and triangulation; synthesis; and return of usable evidence. |
Platform Engineering is included in Systems Engineering, with common Methods and subject profiles. Development Direction Advising is a profile of Problem Structuring and Decision Support, covering the construction and recommendation of development opportunities.
Use the Engineering DPF Suite Reference to find the relevant DPF, combine results from several DPFs for one working question, or identify a specialist contribution that still needs to be obtained.
A DPF, Domain Principle Framework, is an FPF-grounded declarative pattern language for a recurring family of domain difficulties. It turns maintained domain knowledge into reusable patterns that can be selected by their Situation and Question rather than read as a textbook chapter sequence.
A DPF is intended to keep a domain's state of the art (SoTA) usable. Here, SoTA is not equated with the newest official standard, one institutional consensus, or one fashionable method. It is a current, plural, source-linked account of useful approaches, rival schools, evidence, practitioner experience, known failures, trade-offs, and the conditions under which a particular move is warranted. A DPF must preserve disagreement and source-use limits instead of laundering them into one authoritative-sounding recipe.
DPFs depend on FPF Core for transdisciplinary distinctions and do not silently rewrite it. FPF Core does not depend on any one DPF. More DPFs can be added for other domains while retaining the same shared language for cross-domain human–AI work.
FPF becomes useful when an ordinary conversation, document, dashboard, or generated answer no longer keeps difficult Work coherent. Typical signals include:
| What practitioners notice | What FPF helps make explicit |
|---|---|
| A late source, requirement, supplier, or design change returns as rework. | Which claims and decisions relied on the changed source; what must be revalidated; what remains unaffected. |
| A handoff loses scope, configuration, assumptions, evidence, or responsibility. | The exact subject, relation, receiving use, result, evidence limits, assignment, permission, and authority. |
| An architecture decision exists only in meeting memory, a chat, or a diagram. | Candidate structures, interfaces, comparison basis, accepted losses, selected structure, decision, and reopen conditions. |
| A design review compares labels such as build, buy, supplier, reuse, automation, or AI. | Comparable whole obtaining arrangements, including integration, assurance, support, capability, lock-in, and exit burdens. |
| A test, simulation, model, certificate, review, or AI answer “passed,” but nobody can say what it proves. | The claim, subject, conditions, configuration, evidence correspondence, traceability, uncertainty, and decision that may rely on it. |
| Parts are complete, but integration, configuration, commissioning, or actual use still fails. | The bounded configuration, intended use, interfaces, unresolved dependencies, operating evidence, fallback, and release decision. |
| Field failures or operating feedback do not return to design and Method decisions. | The affected architecture, source, configuration, evidence, Method, and decision conditions that must be reopened. |
| The result works once but is hard to maintain, reproduce, transfer, or change. | Maintainability and evolvability trade-offs, support arrangements, capability, tacit knowledge, descriptions, trials, and knowledge transfer. |
| One experienced person knows how the Work is really done, while the procedure says something else. | Method, MethodDescription, capability, actual Work, observed result, local variation, and evidence of transfer. |
| Humans and AI agents produce fluent output but disagree about facts, evidence, permission, or who decides. | Separate claims for capability, assignment, permission, authority, responsibility, evidence, and actual performed Work. |
| A technical explanation or narrative is compelling but cannot be traced back to the source structure. | Source selection, preserved and lost relations, viewpoint, compression, reconstruction checks, evidence limits, and source return. |
For lightweight use, attach or index FPF Core and only the DPF publications relevant to the task. For programmatic access to the current FPF Core reference, use the hosted fpf_reference MCP service, which provides bounded search, structured queries, exact-document lookup, citations, and source-snapshot status. Attach or index a relevant DPF separately unless the current service snapshot explicitly reports that publication as included.
The MCP service is a lookup interface over its indexed FPF publication snapshot. It is not agent memory, a job-state store, a project-policy authority, or an engine that performs the engineering Work.
Describe the actual difficulty, the object at stake, the decision or action that the answer must support, and the evidence already available. Do not begin by guessing a PatternID. Ask the agent to compare a small plausible set of patterns by their declared Situation and Question.
The first answer should improve the current Work: clarify a subject, repair a claim, compare options, identify a missing interface, qualify evidence use, prepare a decision, expose a capability gap, or return an honest blocker. It should not inflate one local question into a complete project methodology.
Ask for plain technical language first, followed by exact PatternIDs and source locations. Require traceability to the relied-on patterns and evidence, plus assumptions, uncertainty, protected trade-offs, missing permissions or authority, and conditions that would reopen the result. Keep human review explicit whenever the result will support a consequential decision.
One result may reveal another concrete question. Apply the pattern that owns that new question. Do not infer a universal sequence from this local dependency.
You have grounded access to FPF Core and the relevant FPF-grounded DPF
publications. Act as an FPF-driven engineering collaborator, not as an
automatic authority or a generic project planner.
Current situation and question:
[Describe the actual project object, difficulty, intended use of the answer,
constraints, available evidence, and decision or action that may follow.]
1. Restate the actual subject, situation, and current question in plain
technical language. Distinguish the engineered System or other object from
its descriptions, models, plans, claims, and records.
2. Compare a small plausible set of patterns by their declared Situation and
Question. Select only the pattern or cooperating patterns whose questions
are current. Do not infer a process from PatternIDs, file order, catalog
order, or example order.
3. Produce the smallest useful result for the current Work, or return an
honest blocker. Help choose the next justified move, but do not invent a
universal project sequence.
4. Keep Method, MethodDescription, WorkPlan, actual Work, result, capability,
assignment, permission, responsibility, authority, evidence, assurance,
and decision distinct whenever these distinctions affect truth or action.
5. Do not treat an AI-generated statement, a fluent explanation, a passed
check, a document, a job title, or a model output as evidence or authority
without the required basis.
6. State assumptions, alternatives, trade-offs, evidence limits, uncertainty,
missing facts or capabilities, and the conditions that would reopen the
result.
7. Explain the result for an engineer who also coordinates specialists,
providers, tools, robots, and AI; negotiates architecture and interfaces;
organizes reviews and working meetings; and makes responsible decisions.
8. After the plain explanation, give the exact FPF/DPF PatternIDs and source
locations used so the result can be inspected.
| Current question | Useful entry |
|---|---|
| What exactly is the project changing, and for which use? | FPF A.1.SCR, A.15.6; Systems Engineering DPF SYSE.1, SYSE.16, SYSE.2. |
| Which functions, bearers, architecture, and interfaces should be selected? | FPF C.30, C.32, C.32.P2S; Systems Engineering DPF SYSE.5, SYSE.6. |
| Should we build, buy, reuse, contract a provider, use AI, or combine them? | Systems Engineering DPF SYSE.24; compare complete obtaining arrangements rather than labels. |
| What can this test, model, trial, review, or observation justify? | FPF A.10, B.3, C.16; Systems Engineering DPF SYSE.4, SYSE.10. |
| Which configuration exists, where does the claim apply, and may it be released? | Systems Engineering DPF SYSE.13, SYSE.14, SYSE.19. |
| Which Work may overlap, and which result dependencies really require order? | FPF A.15.1, E.18.NET; Systems Engineering DPF SYSE.20. |
| Which reusable way of working is current, and does it work in this situation? | FPF A.3.1; Method Engineering DPF ME.1 and the pattern owning the current Method question. |
| What capability is missing for a named family of Work? | FPF E.23.CDI; then use the relevant domain pattern for the Work and evidence. |
| What does current SoTA offer, where do approaches disagree, and what should be maintained as a DPF? | FPF G.2, E.4.DPF; preserve sources, rival approaches, scope, freshness, and stop conditions. |
| How should source material become a technical explanation, learning rendering, or narrative without invented structure? | Narrativization and Narrative Studies DPF NSTD.*, selected by the current narrative question. |
These are entry points, not stages. Most cases need only one direct pattern and should stop when that pattern returns the result needed by the present decision or Work.
A factory team needs more throughput from a filling and inspection cell without sacrificing product quality, maintainability, or safe operation. The first discussion jumps between four labels: modify the existing line, buy an integrated cell, assemble a solution from specialist suppliers, or combine operators, robots, machine vision, and AI agents.
An FPF-driven agent does not begin with a software architecture or a generic transformation plan. It helps the engineer:
- identify the actual project System and the operating use that matters;
- recover affected neighbouring and using Systems;
- compare functional, bearer, and interface alternatives;
- turn the four labels into comparable whole obtaining arrangements, including integration, assurance, support, capability, lock-in, and exit burdens;
- identify which configuration and effectivity range each claim concerns;
- connect trials and measurements to the exact claims they may support;
- distinguish overlapping Work from dependencies that genuinely require order;
- expose capability, assignment, permission, and decision-authority gaps;
- record the selected architecture, accepted trade-offs, evidence basis, and reopen conditions;
- return commissioning and field feedback to the affected design, Method, and decision.
The agent can draft and inspect this result using FPF and the Systems Engineering DPF. Engineers and other authorized participants contribute ground truth, evaluate the evidence, negotiate commitments, and make the actual decisions. The same distinctions apply to a building subsystem, laboratory setup, medical device, robotic product, energy installation, organizational method, research program, or software-intensive System.
| Keep distinct | Why it matters |
|---|---|
| A System and a description, model, dashboard, or document about it | Changing or approving a description does not by itself change the System. |
| A Method, a MethodDescription, a WorkPlan, and actual Work | A procedure or plan does not prove that capable Work occurred or produced its intended result. |
| Architecture, an architecture description, and an architecture decision | A diagram is not the structure; a selected structure is not automatically realized. |
| Capability, assignment, permission, responsibility, and authority | A person, team, tool, or AI agent may have one relation without the others. A title or technical ability establishes none of them by itself. |
| A claim, its evidence, assurance about reliance, and the decision that uses it | Fluent text, a passed test, or a source citation does not support every nearby conclusion. |
| Result dependency, planned Work order, actual Work order, and teaching order | Each answers a different question. None should be inferred from document order. |
| A local decision and a continuing Method or culture | One successful case does not prove transfer, institutional retention, or universal applicability. |
| A narrative rendering and its source structure | Readability and engagement do not guarantee source fidelity, causal validity, or recoverability. |
FPF is not:
- an AI-agent framework, agent runtime, orchestration library, memory service, or autonomous-action permission;
- a software-coding framework, although software-intensive Systems are legitimate engineering subjects;
- a prescribed workflow, project-management methodology, lifecycle, or universal sequence of stages;
- a checklist bureaucracy or a compliance scheme built around official standards;
- a claim that one school, standard, toolchain, model, or institutional consensus is the whole state of the art;
- a replacement for domain expertise, direct observation, experiment, measurement, professional judgement, or legally valid authority;
- a demand that a human read the full specification before obtaining a useful result;
- a guarantee that every project needs every pattern or every DPF.
FPF is most useful when the cost of semantic drift, hidden assumptions, premature convergence, lost handoffs, ungrounded AI output, weak architecture decisions, evidence gaps, rework, or unreviewable collective Work exceeds the cost of using a disciplined pattern language.
This README is a public entry point, not the normative specification. It deliberately coarsens and omits detail. When a claim becomes important, inspect the exact pattern body, definitions, checks, source uses, and stop or reopen conditions in FPF Core or the relevant DPF.
The framework is an eternal alpha: it is usable now and continuously revised as its sources, working situations, patterns, and evaluations change. AI agents should expose the source edition or snapshot they used whenever currentness matters.
Levenchuk, Anatoly. First Principles Framework (FPF).
GitHub repository: https://github.com/ailev/FPF