#First Principles Framework (FPF) Readme

Preface node heading:first-principles-framework-fpf-readme:432

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

First Principles Framework (FPF) is a standards-style pattern language for turning difficult engineering, research, management, and mixed human and AI work into explicit, reviewable, improvable reasoning.

FPF helps when a project has outgrown one clever conversation. It is useful when meanings, claims, options, evidence, architecture, work decisions, publication forms, and improvement criteria need to stay coherent across people, teams, tools, time, or AI agents.

Use FPF as a reference model and pattern language, not as a linear textbook. Start from the working question you bring from your project. Bring in internal FPF terms only after they help you keep the work precise.

This readme is a thin public practical-use rendering of FPF for engineers, researchers, managers, reviewers, and AI-assisted project workers deciding what FPF can help them do now. It foregrounds the project questions most likely to pay off and deliberately coarsens, omits, or defers the full pattern language, source publications, source-use history, and relation structure. When a claim becomes important, use the Preface and Table of Contents as locators, then inspect the exact definition, constraint, test, method, evidence rule, or assurance rule needed for that claim in the cited pattern body; do not treat this readme as the specification.

Begin with the project object at stake and the current question about it. FPF often calls an object a holon when it is being treated as a whole with parts: a machine, product, organization-as-system, body of knowledge, publication system, work occurrence, discipline, AI-agent arrangement, method, or local framework admitted under part-whole treatment.

Bare claim-bearing role has no single FPF referent. Start with E.10.ROLE, then continue through the object or relation it recovers. If the recovered wording is a claim-bearing function use, apply A.6.F and its selected subject pattern. Do not choose a branch from the trigger word alone. Once the object and question are named, ask which structure, claim, decision, evidence, description, Work, or improvement relation is current.

#Practical entries

The entries below are examples, not a catalogue or a boundary around FPF, a DPF, or an LPF. Bring the actual difficulty from your project. If no example fits, search the Table of Contents or ask an assisting agent to compare a small plausible set of direct patterns. These pattern languages can help with many more questions than a short Readme can show.

The ordinary examples show difficulties that one direct pattern use can usually answer. They need no mantra. The Practical-Use Cards show another use: a difficult question whose answer normally draws on several pattern contributions. Their mantras show in compact form how that answer unfolds through those contributions, without turning the unfolding into a fixed workflow.

#LIVE-WORK-STEERING — Choose the next action while Work is changing

• Situation: Ongoing Work has an applicable domain Method, but a current fact can change what should happen next.
• Question: What should the deciding System choose now, who will perform it, and when must they stop or look again?
• First useful result or honest blocker: One bounded decision, intended performer, and feedback condition—or a named blocker due to missing or outdated action-guiding information, authority, capability, safety, applicability, or no current Work.
• Start with: A.15.7.
• Stop or return: Stop when the action, performer, and nearest return condition are clear. If ongoing Work is blocked by a missing or unsupported performer, support, or continuation-state relation rather than by candidate choice, use A.15.8 to repair that configuration or stop, then return. If Work has not begun, use A.15.2 for intended-work content, A.15.5 for work-entry readiness, or C.11 only when a known chooser must compare an already formed OptionSet.

#METHOD-RECOVERY — Explain what reusable way several performances may show

• Situation: Several observations or records suggest a reusable way, but no Method has been established.
• Question: What candidate explanation is supported, what rival still fits, and what observation would distinguish them?
• First useful result or honest blocker: One source-traceable account per candidate with gaps and a distinguishing question—or an honest record-only result.
• Start with: A.3.1.MR.
• Stop or return: Stop at the strongest honest account or lowering result. Continue to A.3.1 or specialist ME.18 only when that later use is current.

#PROFESSIONAL-RESULT — Use one result from another practice without transferring the decision

• Situation: A decision needs a legal, safety, tax, privacy, engineering, scientific, or other outside-practice result, but the available source or request names only a title, department, document, approval, provider, or tool.
• Question: What smallest result can change this decision, and is an already-available result current and qualified for that exact use?
• First useful result or honest blocker: A bounded decision to reuse the existing result, a request for the smallest missing result, or the exact source, Method, capability, authority, access, evidence, or applicability blocker.
• Start with: A.15.9.
• Stop or return: Stop before requesting new Work when the existing result is enough. The supplier keeps its Method and professional authority; the receiver keeps the receiving decision. A title, document, delivery, provider label, or tool output transfers neither.

#NAMING — Give one identified thing a usable name

• Situation: One already identified thing needs understandable wording; later use may also require a stable, reusable name.
• Question: Does ordinary wording suffice, or which durable name preserves the thing and avoids misleading alternatives?
• First useful result or honest blocker: Sufficient ordinary wording; only when reuse needs a durable settlement, one local NameCard; otherwise the exact missing thing, use, reader group, scheme, sense, or candidate evidence.
• Start with: F.18 when the name must become durable. For one-off wording, keep the ordinary phrase and use the thing's direct pattern only if its meaning is unclear.
• Stop or return: Stop without a card when ordinary wording answers the need; otherwise stop at the local naming settlement. Return when the thing, use, readers, scheme, or likely misunderstanding changes.

#SYSTEM-RECOGNITION — Test systemhood only when it changes the decision

• Situation: A decision may change if one exact entity is a System, while the same noun may instead name Work, a Method, capability, episteme, structure, or another subject.
• Question: What decision depends on treating that entity as a System?
• First useful result or honest blocker: Return to the direct non-system claim; recognize or reject the System reading; or name the missing construction fact or test.
• Start with: A.1.SCR.
• Stop or return: Stop at that direct result or exact blocker. A noun, assignment, capability, plan, or project label does not establish systemhood.

#TIME — Decide what a timing claim lets you do

• Situation: A trend, deadline, cadence, or stale result is being used to decide what to do next.
• Question: Which moment, rate, rhythm, or freshness relation matters, and does it support continuing, refreshing, waiting, synchronizing, or changing rhythm?
• First useful result or honest blocker: A bounded temporal claim and supported continuation, or the exact missing window, evidence, effort, resistance, or currentness basis.
• Start with: C.27; use G.11 only when an affected result may need scoped refresh because its basis is stale.
• Stop or return: Stop at a state or rate reading when it supports no stronger claim. Return when the window, evidence, currentness, or intended use changes.

#CAUSAL-USE — Keep a causal-looking result within its support

• Situation: A correlation, estimate, simulation, or comparison is being used to say that an action will cause an outcome.
• Question: What causal statement may the evidence support, and what stronger statement must not guide intervention or investigation?
• First useful result or honest blocker: A supported statement and its limit, or the missing alternative, intervention, comparator, evidence path, identification result, or transport basis.
• Start with: C.28.
• Stop or return: Stop, narrow the claim, or abstain when support is insufficient. The causal-use result does not choose, deploy, publish, or certify by itself.

#MEASUREMENT — Make a number interpretable before relying on it

• Situation: A reading, score, rating, sensor value, or dashboard number is being compared or used in a decision.
• Question: What exact subject and characteristic were measured, on what scale and unit, by what method, and under what calibration and time stance?
• First useful result or honest blocker: An interpretable attributed value with uncertainty and a use boundary, or the missing subject, scale, method, calibration, evidence, or validity window.
• Start with: C.16.
• Stop or return: Stop when the value supports the present comparison. Return when the subject, method, calibration, time stance, uncertainty, or use changes.

#MATHEMATICAL-MODELING — Use a mathematical lens only when it changes action

• Situation: A formula, formalism, simulation object, or learned representation is proposed to clarify a project question.
• Question: What is mapped to what, which structure is kept or lost, how is the lens calibrated, what rival or ordinary fallback exists, and what decision changes?
• First useful result or honest blocker: A bounded lens use with its mapping, retained and lost structure, calibration, rival, practical payoff, and no-lens exit, or the exact missing basis.
• Start with: C.29.
• Stop or return: Stop without the lens when no decision changes. Return when the mapped subject, preserved structure, calibration, evidence, rival, or use changes.

When the direct pattern is already known, open it rather than forcing the question into an example: E.11.PFP for framework publication, E.11.DSG for the DPF Suite Reference when a question spans several DPFs, A.15.6 when project, process, or case hides the subject, A.1.1 for model-use organization, C.22.PFR for an actual-problem claim, and A.6.REL for an obtaining relation. These are locators, not more selectable examples.

#Practical-Use Cards

These cards offer a non-exhaustive set of optional routes for extended work with a pattern language, each selectable by its situation and intended result and composable only from contributions current in the actual case.

The keys only help navigation. Compare cards by the situation and intended result, then open the direct patterns needed in the actual case. Skip a contribution whose question is not current, and stop at the first useful result or honest blocker.

#ARCHITECTURE — Carry an outside need through structure and feedback

• Situation: A system or another architecture subject must produce an outside result, but its pressure, options, decision, or realized feedback is unclear.
• Question: What missing architecture result prevents the next useful decision or action?
• First useful result or honest blocker: One clear architecture question, candidate comparison, decision, or exact missing fact or constraint.
• Mantra: Start with the outside change and who relies on it. Name the subject and pressure; separate facts from intended constraints; compare plausible structures; choose what the current decision needs; check what the realized structure produces; reopen when use, evidence, or structure changes.
• Start with: C.32.P2S, then the pattern for the current question in C.30, C.32, C.32.PAD, or C.30.AD.
• Stop or return: Stop when the first result makes the architecture work reviewable. The card is not a compulsory lifecycle.

#PRACTICE-ARCHITECTURE — Develop a practice without collapsing its structures

• Situation: Methods, Work, capabilities, providers, descriptions, tools, and cultural change do not align one-for-one in a practice.
• Question: Which relations must be reconciled for the practice to become usable or improve in representative Work?
• First useful result or honest blocker: One readable synthesis, one bounded development action, or the exact missing Work case, relation, or transfer evidence.
• Mantra: Start from representative Work and its needed result. Keep Methods, Work, capabilities, providers, descriptions, tools, and cultural processes distinct; compare the structures that conflict; develop the limiting capability; test transfer in real Work; return when practice, provider, evidence, or style changes.
• Start with: C.32.MWA; use E.23.CDI, E.23, or C.36 only for the question actually opened.
• Stop or return: Stop when the synthesis or transfer result answers the decision. A practice description is not the practice or performed Work.

#WORKING-DOCUMENTS — Make a document answer one use

• Situation: A document is requested, but its label does not reveal the use it must support.
• Question: Do you need to check one view, reuse related views, show the same subject differently, see enough structure, compare named sources, or use an architecture description in a decision?
• First useful result or honest blocker: A checked view, a reusable viewing approach, another presentation of the subject, an account of sufficient or missing structure, a source comparison, the architecture-description result needed now, or the exact blocker.
• Mantra: Name who will use the document and what it must support. Check one view; prepare recurring views; show the subject another way; expose enough structure; compare sources; or use a description in architecture work. Keep document, subject, decision, and performed Work distinct. Stop when the needed result exists; return when its use or content changes.
• Start with: E.17.0 for one viewpoint; E.17.1/E.17.2 for recurring use; A.6.3.RT for representation change; C.33 for structural information; E.17.ID.CR for source comparison; C.30.AD for architecture-description use; otherwise use the direct pattern for the document result.
• Stop or return: Stop when that result answers the use. One file may carry several results without merging them.

#COMMUNICATION-FOR-USE — Make communication useful, then learn from what happens

• Situation: A report, model, message, or answer seems clear, but its intended use and evidence are unclear, including whether its producer can use it later.
• Question: Who should understand or do what with it, what evidence is enough, and what should change if that use is not achieved?
• First useful result or honest blocker: A supported decision to keep or repair it, change prerequisites or a future use, or stop, with evidence, causation, and permission limits.
• Mantra: Name who should understand or do what. Judge the act of communicating against that use. Keep the act distinct from its wording and medium; separate interpretation, response, later action, world change, and causal contribution. Repair wording, representation, prerequisites, medium, interaction, or a future use—or stop. Check authority, consent, and admissibility separately. Do not rewrite the earlier use after seeing the response.
• Start with: A.2.9 for communicative Work; A.6.3.CR for wording; A.6.3.RT for representation; A.6.3.NAR, E.17.EFP, or E.24.PUB for narrative, explanation, or publication. A.10 for evidence, C.28 for causation, and C.11 only to compare repair options.
• Stop or return: Stop when the named use has enough support or a blocker is explicit. Response or silence alone proves neither meaning, success, causation, authority, consent, nor permission.

#OPTION-COMPARISON — Keep unlike option results distinct

• Situation: A candidate list mixes labels such as build, buy, reuse, provider, internal, outsource, or AI; or one unresolved question makes a costly commitment unsafe.
• Question: Must you form complete ways to obtain one result, compare or retain them, govern a pool, prepare a set for another chooser, choose now, or resolve the uncertainty blocking commitment?
• First useful result or honest blocker: A complete-enough same-result way set, comparison or retained set, pool rule, prepared OptionSet, ChoiceResult, answer to the blocking question, or exact gap.
• Mantra: Name one result, use, situation, horizon, and acceptance basis. Turn labels into complete ways on one parity basis, keeping supported, proposed, and unknown premises visible. Compare or choose only when current; preserve worthwhile variants and gaps. For costly action, resolve only the uncertainty blocking commitment. Return when the result, basis, evidence, or use changes.
• Start with: C.38 when labels or fragments need complete ways; otherwise open only the current branch in A.19.ECS, C.18, C.19, G.5, or C.11. For costly action, use only the current check in A.10, B.3, A.20, A.21, C.28, C.11, or A.15.5.
• Stop or return: Stop at the result for the present question. An option description does not choose or establish capability, authority, Work, provision, delivery, acceptance, or use.

#RESULT-TO-NEXT-MOVE — Route an obtained result to the next probe or option

• Situation: A DPF or project calls something information gain, learning progress, novelty, or a former cue and wants it to change the next probe or option.
• Question: What result actually exists, and which downstream question, if any, is current?
• First useful result or honest blocker: The direct result plus the first needed reliance disposition, characterization, possibility-space claim, configuration-relative comparison, ChoiceResult, or missing basis.
• Mantra: Name the result; split ambiguous learning claims; keep each with its direct pattern. Move only to the current question: relied-on evidence, characterization or possibility space, realizable configuration comparison, or live choice. Stop when the present question is answered.
• Start with: Use E.10.LRN only to recover a result hidden by learning; otherwise its direct pattern. Then use A.10 only for actual reliance, C.17/C.18 only for characterization/space change, C.11.CRC only for a missing finite configuration comparison, and C.11 only for a live choice.
• Stop or return: Stop before every non-current question. Observation, objective, former cue, and characterization retain their identities; this card creates no generic signal, cue, qualification, or choice.

#ACTUAL-TEMPORAL-STRUCTURE — Recover what actually obtains before testing coordination

• Situation: A cycle, onset list, trace, notation, or geometry is called rhythm, but may be a prescription, representation, Method unfolding, or account rather than what obtains.
• Question: Which subjects and relations support one actual selected structure, what grounds it, and what coordination change should be tested?
• First useful result or honest blocker: One A.22-selected structure and grounded C.2.1 account—or the missing bearer, relation, observation, or grounding. Keep future specifications and representations separate. For coordination, add direct relations, trial conditions, observations, and next decision or stop.
• Mantra: Start with actual changing subjects and use. Recover changes, Work parts or continuous carrier, plus exact obtaining relations. Select one structure; ground only supported account. Keep structure, account, future specification, representation, Method unfolding and Work distinct. For coordination, name bearers and direct relations; compare interventions, try one in bounds, observe, then decide or stop. Never infer structure from periodicity, onsets, notation or geometry.
• Start with: A.3.4/A.15.1 for change/Work, C.27.TA/A.22 for claim/structure, C.2.1 for account; add specification, representation, decision, causal, trial, or domain patterns only when current.
• Stop or return: Stop when use is answered. Return when bearer, relation, constraint, grounding, intervention, or use changes; domain Methods stay in DPF.

#PROBLEM-SHAPING — Stop at the earliest honest problem-side result

• Situation: Something matters, but the team may have only signals worth preserving, a direction for inquiry, a question about competing explanations, or enough clarity to accept a problem statement.
• Question: What can you honestly produce now: preserved signals, a routed direction for inquiry, an explicit question that contrasts possible explanations, or a problem statement ready for acceptance?
• First useful result or honest blocker: A preserved set of signals, a clear inquiry route, a question about plausible explanations, an accepted problem statement, or the exact missing anchor, route, subject, constraint, or acceptance basis.
• Mantra: Keep what was noticed before declaring a problem. Route the inquiry only when the signal has a stable anchor. Ask about explanations only when the open question and contrast are clear. Accept a problem statement only when the subject, constraints, unresolved relations, important distinctions, and basis can be stated. Stop at the earliest useful truth; return when its basis changes.
• Start with: A.16.1 for a cue pack, B.4.1 for routed cues, B.5.2.0 for an abductive prompt, and C.22.2 for an accepted ProblemCard.
• Stop or return: Do not force a cue into a problem. Open C.22.PFR only when whether the adverse relation obtains changes the next use.

#IMPROVEMENT — Define better before repeating change

• Situation: A team wants to improve something but has not agreed what better means or how the changed version will be checked.
• Question: Which evaluation question, characteristics, scales, changes, and comparison make improvement reviewable?
• First useful result or honest blocker: One evaluation question, current assessment, bounded change, before-after comparison, or exact missing use, evidence, scale, or trade-off.
• Mantra: Name the entity, current state, and use that better must serve. Frame the question before choosing metrics; select characteristics, scales, and protected trade-offs; assess the current state; compare candidate changes; make only the supported change; evaluate it on the same basis; continue, stop, or change direction from that result.
• Start with: E.22, A.19.ECS, C.16, and E.23 as their questions become current.
• Stop or return: Stop at the first missing prerequisite or useful comparison. Reopen when the entity, use, evidence, or scale changes.

#WORDING — Repair language without replacing the project question

• Situation: A load-bearing sentence hides the subject, relation, kind, use, or nearby false inference.
• Question: What should the reader understand and do, and which distinctions matter for that use?
• First useful result or honest blocker: One plain repaired sentence, direct clarification, local naming result, or exact missing subject, sense, test, or reader use.
• Mantra: Recover the ordinary project sentence first. Name what it is about, what it claims, and who must use it; add ontological distinctions only where they change truth, understanding, or action; choose a durable name only when later use needs one; rewrite in plain technical language; check the result with a cold reader; retain a guard only under F.19's full grounded-contribution test; return to the domain task.
• Start with: F.19; use E.10 for unresolved FPF wording, and F.18, F.0.1, F.9, or the subject's direct pattern only when needed.
• Stop or return: Stop when the reader can understand the claim and carry out its intended use. Do not continue ontology work after the language problem is solved.

#SOTA-PORTFOLIO — Move from a plural field to the cheapest useful result

• Situation: A project needs the modern field of approaches rather than one popular answer and may later need maintained domain guidance.
• Question: What plural view is adequate now, and does the remaining problem call for reuse, a contribution, another product, a DPF or LPF, or no maintained result?
• First useful result or honest blocker: One source-linked SoTA view, live option set, reuse route, framework decision, or exact missing scope or maintenance basis.
• Mantra: Name the practical question, scope, freshness need, and rival traditions. Build a source-linked plural view; preserve disagreement and source-use limits; compare useful approaches; try cheaper reuse or contribution first; open a framework decision only for a recurring unmet problem; author and test the needed patterns; refresh when the field or use changes.
• Start with: G.2; add C.18, C.19, or G.5 for the set and the E.4/E.9 authoring route only if a framework is selected.
• Stop or return: Stop at the first adequate maintained or one-off result. A source pack or proposal is not a framework by appearance.

#SYSTEM-DELIMITATION — Separate parts, selected boundary, and crossings

• Situation: One System is recognized, but a decision mixes its parts and assembly with a chosen boundary, external participants, and relations that cross it.
• Question: Which facts, use-relative choice, crossings, and selected structure answer the decision?
• First useful result or honest blocker: One exact part or assembly fact, boundary choice, crossing relation, selected structure, or missing participant, predicate, constraint, or use.
• Mantra: Start with the recognized System and decision. Recover parts and assembly as facts; keep external participants outside the part list; choose a boundary only when alternatives matter; name every crossing by its own relation; select a joint structure only when organization changes the decision; reopen when identity, facts, use, crossings, or constraints change.
• Start with: B.1.2, A.14, and C.13; use C.11, C.32.PAD, the direct relation pattern, or A.22 only when needed.
• Stop or return: Stop at the smallest result answering the decision. If system recognition is unresolved, return to A.1.SCR.

#CONSEQUENCE-BEARERS — Find omitted Systems before closing a decision

• Situation: A change has one plausible receiver, but the list may omit other physical or operational wholes that can change.
• Question: Which other Systems may undergo a relevant change, through what supported relation or still-modal path, and what should the receiver do next?
• First useful result or honest blocker: An affected-System consequence account naming the focus; one or more bearers or intended referents; obtaining or modal path; possible changed characteristic; support, uncertainty, receiver connection, and residual; plus the next probe or stop—or the missing System-recognition or relation fact.
• Mantra: Name the focus and receiver; generate concrete possibilities; trace obtaining relations and modal paths separately; challenge the boundary; recover real holons instead of a level ladder; qualify each changed characteristic; keep the sides distinct; return the cheapest probe, constraint, alternative, monitoring condition, or honest stop.
• Start with: A.1.CSD; use A.1.SCR only when a candidate's systemhood is load-bearing, and leave through the direct evidence, causality, comparison, domain, or value pattern only when that stronger question is current.
• Stop or return: Stop at the smallest account that changes or holds open the named decision or investigation. Return when the focus, configuration, horizon, whole, relation support, bearer, observation, or receiving use changes.

#Decide Whether FPF Fits

Use FPF when ordinary discussion is no longer enough to keep work coherent. Typical signs:

• several teams, experts, tools, or AI agents share reasoning about the same work;
• the real-world test is slow, expensive, noisy, risky, or politically hard to repeat;
• different readers need different reports, dashboards, explanations, or decisions about the same underlying work;
• names, roles, responsibilities, options, evidence, or quality criteria are starting to blur;
• the team needs a current view of possible approaches, not just one recommendation;
• a decision is small enough to make now but important enough to leave a durable reason.

FPF is probably too heavy when the task is small, feedback is fast and cheap, the vocabulary is already stable, the decision will not be reused or audited, and a quick answer is enough.

FPF is mainly useful for people who have to keep difficult work understandable across boundaries:

• engineers and systems engineers working with complex products or operations;
• researchers building claims for inspection or reuse by others;
• platform and AI teams coordinating humans, models, tools, and approvals;
• safety, assurance, compliance, and regulatory leads who need visible evidence and responsibility boundaries;
• managers and product leaders comparing options, budgets, risks, and delivery promises without hiding trade-offs.

There are three common ways to use FPF:

1. Human-only: use it as a writing and review discipline for meetings, notes, decisions, and technical documents.
2. Mixed team: use it to keep specialists, managers, safety leads, and AI assistants aligned around the same work.
3. AI-assisted: attach or index the specification, ask for plain-language project help first, and use pattern names only when they make the answer easier to check.

Stronger AI does not remove the need for FPF. AI can generate fluent options quickly, but projects still need to decide what counts as evidence, which option is being compared, who may rely on an answer, when a claim is stale, what remains only a guess, and what work is actually authorized. FPF helps make those boundaries explicit before a confident answer becomes an expensive mistake.

Core ideas in plain language:

• first name the project object under concern; when it is treated as a whole with parts, FPF calls it a holon;
• local teams may use local meanings; boundary-crossing work makes the translation relation explicit;
• the project object itself, its description, a dashboard about it, a decision about it, and the work done to change it are not the same;
• architecture is structure of that holon or project object in a context, not the diagram, document, approval, or plan about it;
• serious architecture work can move from problem pressure to candidate structures, selected structures, decisions, method and work, actual structures, and feedback;
• when the current question is which reusable way of doing changes, produces, derives, selects, controls, or preserves the project object under stated conditions, inspect A.3.1 U.Method; a strategy name, procedure text, program, plan, dated run, mechanism, or evidence record does not answer that method question by its label or form;
• when one already-selected method, model, formalism, assurance technique, ontology, or other apparatus is current and its setup/application cost must earn one declared use, inspect C.19.2; it defines and tests one bounded application to a separately identified problem-facing result and guarantee. Open C.18 only when an adequate candidate must be generated or reframed, and C.11 only when two or more eligible alternatives make a real local choice current;
• when a clear engineering claim produces a wrong action, identity, dependence, obtaining, responsibility, or projection consequence, inspect A.7.1; when current FPF uses produce incompatible consequences for the same receiving claim and scope, inspect A.7.2. In either case, keep the method episteme, admitted performer, dated work, the claim-specific result returned by the applicable pattern, and one result episteme distinct: the local disposition is a value in that result, not its kind, and A.7.2 need not converge;
• when an accepted C.22.2 ProblemCard episteme must remain usable while the project selects a method, prepares or performs work, interprets a result, branches, stops, or returns after a changed assumption, inspect E.18.1 P2W Problem-to-Work Carry-Through; it carries the accepted problem-side distinctions into one next value or relation returned by the pattern that answers the current question rather than prescribing one universal workflow;
• when route-like positions, relations, or constraints change which continuation remains possible, inspect E.18.3: begin with the concrete thing being transformed, two recognizable places or states, the proposed connection or guard, and the current continuation question. An ordinary provisional explanation may answer it or stop with the exact missing predicate or occurrence rule, missing case fact, or unavailable information. Recover exact A.22/E.18 qualification and a separate demonstrative-slice claim only when qualification, comparison, publication, or stronger reliance is current; if no branch, connection, or constraint changes the continuation question, keep an ordinary route description;
• keep several options alive until the comparison is clear enough to choose;
• say what "better" means before optimizing or scoring;
• make trust depend on evidence, freshness, scope, and intended use;
• publish different views for different readers without changing the underlying claim;
• when explanation, reader-facing ordering, or narrative rendering of selected source structure is current, state what structure is preserved, deliberately coarsened, abstracted, omitted, or lost; name the source-return condition and any stronger neighboring claim together with the concrete definition, constraint, test, method, evidence rule, or assurance rule it uses;
• use mathematics or formal models when they clarify what structure is preserved, what is lost, and what can be checked;
• build domain or local FPF-grounded frameworks as dependents of FPF Core, not as silent rewrites of the Core.

#When Several Transformation Flows Form One Network

Inspect E.18.NET when the current question joins independently identified transformation-flow structures through exact direct relation occurrences. Several stages, several paths, or several valuations of one flow do not make a network.

• Build the builder. A compiler-source-change flow, a bootstrap-compiler build flow, an application build flow, and a deployment-and-operation flow keep their own changes, work, positions, and local state. Recover the project's exact relation that says which executable compiler is used for the application build and its exact delivery relation to deployment. A selected tool-build network can itself be a member of a selected release network; follow a finite member path rather than inventing “level 2” and “level 3” kinds. Inspect E.18.NET; if the case is only one flow with several stages or valuations, stay in E.18.
• Change a product and its production system. Product-development Work changes and verifies the product definition; production-system-change Work redesigns, retools, and qualifies equipment; production Work makes units; operation supplies observations that may inform later product-development Work. Treat their transformation-flow structures as separately identified selected structures: the structures organize positions and exact relations but do not perform the Work. Keep the product and production system distinct, and recover the exact release, readiness, production, and observation relations needed by the current case. A selected product-development network and a selected production-system-change network can be members of a larger selected network without becoming one giant flow. Inspect E.18.NET; if only one architecture correspondence is current, use its direct architecture pattern instead.

When the immediate question is whether dated Work actually occurred or whether an entity was actually produced, leave the network overview and apply the tests in a finite order. First A.13 recovers every actual performer System's core: exact admitted System, local agential kind and criterion, classification, obtaining assignment for the scope, working situation, and window, and adequate core evidence; add a characteristic profile only when conditionally consumed. Next A.15.1 independently admits one U.Work occurrence from the exact performance history, at least one Method actually followed, temporal extent, and at least one obtaining locally declared containing-System relation. That admission neither assumes nor requires F.6. Only afterward, when the receiving use needs precise assignment-bound performer attribution, F.6 tests performedUnderAssignment through the same obtaining A.13 assignment, direct case fact, holder equality, declared species and participants, and coverage. If that relation is unresolved, retain the admitted Work and lower only the attribution. A compact attribution sentence may omit an assignment identifier that its receiving use does not need; the omission changes only the sentence, not those facts. A log, ticket, or record creates neither Work nor attribution. After that Work and the required participant facts are exact, A.15.PROD separately tests the Work's participation in producing the entity, the start of that entity's identity, and production completion. Missing agency basis, Work granularity, production-participation predicate, identity-specification or inception basis, completion criterion or applicability, boundary or composition facts, or required substrate is a branch-local blocker. Actual change, output or result, identifier allocation, evidence, delivery, and acceptance remain separate claims and none proves those three production claims by itself.

#Recover a lost path from outside use to recursive builders

Use this guide when the team has recovered or is explicitly proposing one project system-of-interest but can no longer show how a local result supports the expected outside change, release or runtime use, architecture, Work and change of that system, creator systems, and recursive build-the-builder branches. Open A.1.STM to locate the first unsupported result, select the particular pattern contribution that answers that claim, and state one next question or action or an exact stop.

This is a readable continuation, not an additional practical-use card, result kind, SystemThinkingMap, project-network result, mandatory traversal, WorkPlan, or calendar order. If the actual versus intended project system-of-interest or its project designation is unclear, apply A.15.6 first to distinguish actual project Work, intended material, and project designation. Apply A.1.SCR to the recovered exact entity only when recognition under U.System remains load-bearing for the named decision.

#One-Minute Example

A platform team asks:

Should we buy, fine-tune, or build an agent stack for our product?

Without FPF, the conversation often mixes architecture, vendor comparison, safety, evidence, budget responsibility, user value, and implementation planning. The loudest option can win before the team knows what is being compared.

With FPF, the first pass can become a small set of explicit project objects:

• holons in play: the product, the agent stack, and the team or toolchain that will change it are not the same holon;
• architecture flow: what problem pressure should become which candidate, selected, expected, and actual structures;
• comparison frame: which alternatives are in the candidate set;
• evaluation characteristics: cost, latency, controllability, safety, maintainability, time to first use, and other project-specific characteristics;
• evidence gaps: which test result makes commitment admissible;
• current decision state: whether the team is choosing now, keeping a selected set, making a project architecture decision, or doing more discovery;
• work and feedback: which method, readiness, and performed-work records establish that the selected structures were actually realized;
• reader reliance: what engineering, management, and assurance readers may responsibly rely on.

That same shape can be used for a factory modernization, laboratory protocol, construction design change, supply-chain decision, safety case, or research program. The point is not the AI topic; the point is one body of reasoning that can be reviewed, improved, and published without changing meaning on the way.

#What FPF Is

FPF is a pattern language for disciplined thinking in projects where ordinary prose, local expert judgment, or one-off AI output is not enough.

It helps teams:

• keep meanings stable when work crosses teams, tools, documents, and time;
• separate the project object being discussed from diagrams, dashboards, explanations, promises, decisions, and actual work;
• state what a claim can responsibly be used for before people rely on it;
• compare options without collapsing too early to one favorite;
• define quality criteria before improvement starts;
• keep evidence, assurance, decisions, and implementation work visible as different questions;
• carry architecture work from problem pressure to real structures and feedback instead of stopping at diagrams or decision prose;
• grow domain or local frameworks from FPF Core without silently changing Core meaning;
• repair confusing wording by first asking what the wording is doing in the project, not by swapping synonyms;
• leave each pass with one useful next result: a clearer question, a better name, a comparison note, an evidence gap, a safer document, or a reason to inspect a specific pattern.

#What FPF Is Not

FPF is not:

• a shrink-wrapped project methodology;
• a checklist bureaucracy;
• a quick-answer cheat sheet;
• a replacement for domain expertise;
• a demand to study the whole specification before useful work begins;
• a promise that every project needs every pattern.

FPF is most useful when the cost of semantic drift, premature convergence, hidden evidence gaps, weak architecture, vague quality, or unreviewable work is higher than the cost of using a disciplined pattern language.

#How to Use This Repository

Start with one of the ordinary examples or one of the cross-pattern cards when it recognizes the current project question. A direct example is enough when one pattern can return the needed result. A card helps when the answer must retain several pattern contributions, checks, and returns. If no example fits, use the Table of Contents or ask an assisting agent to compare a small plausible set of direct patterns. The examples are not a list of all questions FPF can help with.

Use the Preface for the cross-cutting ideas. Use the selected pattern body for its Solution. Once one pattern is current, use E.11.PUA to follow that Solution to the smallest useful result or an honest missing-basis stop. Name a receiving use only when an actual continuation or later reliance is current. Use E.11.PUR when applicability, recommendation, coordination, or ordering among candidate pattern uses is the current question. Keep an ordinary reversible judgement conversational; make it addressable only when a named later use needs that support.

If you use an AI assistant, attach or index FPF-Spec.md and ask for plain-language project help first. Let internal pattern names enter only when they make the answer more precise.

A good first prompt is:

You have the FPF specification as a file.
Help me with this current project question:
[short project description and question]

Use plain language for engineer-managers. The Readme examples are clues,
not a list of the questions FPF allows. If one direct pattern can answer
the difficulty, start there. If the answer needs several pattern
contributions, give me a short attention map and open only the
contributions whose questions are current.

First give one useful result for the situation, or an honest blocker.
Then name the project question that result answers and any missing fact,
rule, evidence, or authority needed before a truthful answer is possible.
Add PatternIDs after the plain explanation so I can inspect the direct
Solutions and checks. Stop when the current question is answered; do not
turn the example or card into a whole-project plan.

#Citation

If you use FPF, please cite:

Levenchuk, Anatoly. First Principles Framework (FPF).
GitHub repository: https://github.com/ailev/FPF

Last Updated: 2026-09-03 — upstream FPF commit b999972c (github.com/ailev/FPF)