First Principles Framework (FPF) - Core Conceptual Specification

Operating system for thought for engineering, research, and mixed human/AI teams.

Author: Anatoly Levenchuk (with AI-agents assistance)
Version: March 2026
Status: Normative kernel, "eternal alpha" - already used in working projects and development programmes, while still evolving.

FPF helps when the bottleneck is no longer raw ideation, but coordination.

It turns a vague multi-actor problem into:

• a bounded-context map and a stable shared vocabulary,
• explicit decision criteria, route guards, and comparison characteristics,
• a small portfolio of lawful alternatives or next routes,
• an evidence / test gap list, gates, and auditable hand-offs,
• a durable working form such as a UTS, a DRR, or another route-specific output form,
• aligned outputs for engineers, managers, researchers, and auditors.

Use FPF when:

• work is split across specialists, teams, or AI agents;
• the real-world oracle is slow, expensive, noisy, or risky;
• different audiences need different views of the same underlying work;
• your current vocabulary is breaking down;
• you need state-of-the-art (SoTA) work as a managed portfolio, not a leaderboard snapshot.

Do not start here when:

• one person or one team can solve the task end-to-end,
• the vocabulary is already stable,
• feedback is fast and cheap,
• the cost of semantic drift is low,
• or you mainly need a quick answer, not durable shared artefacts.

Start here

FPF is a core conceptual specification and pattern language with multiple entry routes for engineering, research, and mixed human/AI teams. It is most useful when the hard part is coordination, vocabulary stability, explicit trade-offs, and clean hand-offs.

Choose your first route by the first honest burden, not by document order. If you are new to FPF, read the route title and opening sentence first; use the pattern IDs only after you know the route matches your situation.

A first practical session should usually leave:

• a map of who means what and where the hand-offs are;
• explicit decision criteria, comparison characteristics, or route guards;
• a small alternative set when selection is part of the burden;
• a visible list of missing evidence or tests before commitment;
• a starter UTS (a structured term sheet for unstable or overloaded vocabulary), a starter DRR (a short decision-rationale record), or another route-specific output form.

If you first need to decide whether FPF fits your situation, start with E.1-E.2. If you need to write or review patterns, start with E.8 and E.19.

Use this repository as a route menu, not as one universal starter trunk:

1. Project alignment
   Use this when: the team keeps mixing up responsibilities, working method, plans, and what actually happened.
   You will leave with: a clean separation between responsibility, method, plan, and actual execution, plus a first work sheet or alignment frame.
   Start with: A.1.1, then A.15, then A.15.2 / A.15.3, then B.5.1. Add F.11 when method/work vocabulary itself must be aligned across contexts, and F.9 where bridge discipline matters. Land on F.17 (UTS).

2. Partly-said / language-state discovery
   Use this when: you have a serious cue, concern, or emerging idea that is too important to ignore but too early to present as a settled claim, requirement, or work record.
   You will leave with: a short preservation-and-routing note or cue pack that says what was noticed, how mature it is, and who should receive it next.
   Start with: C.2.2a, then C.2.LS / C.2.4-C.2.7, then A.16 / A.16.1 / A.16.2, then B.4.1 / B.5.2.0, and only then move into the relevant endpoint owner.

3. Boundary unpacking
   Use this when: contract, API, protocol, compliance, or SLA language is mixing rules, gates, duties, and evidence in one blurred boundary story.
   You will leave with: a Claim Register, meaning a split list of rules, gates, duties, and evidence claims.
   Start with: A.6, then A.6.B, then A.6.C. When the boundary text hides overloaded quality language or generic doing-words, continue with A.6.P, then A.6.Q or A.6.A.

4. Lawful comparison / selection
   Use this when: you need to compare alternatives honestly, keep a disciplined shortlist live, or make a selection without hiding the comparison logic.
   You will leave with: declared characteristics, a comparison frame, and sometimes a shortlist or acceptable option set rather than one forced winner.
   Start with: A.19:0, then A.17-A.19, then G.0, then A.19.CPM and A.19.SelectorMechanism, and then G.5.

5. Generator / state-of-the-art / portfolio kit
   Use this when: your first deliverable is a reusable search / harvest / portfolio scaffold, not a one-off recommendation.
   You will leave with: a reusable kit that names scope, schools of thought, variants, and shortlist-ready outputs.
   Start with: A.0, then G.0, then G.1, then G.2 and G.5. When creative search or explore/exploit policy is already central, add B.5.2.1 and C.17-C.19 early.

6. Same-entity rewrite / explanation / comparative reading
   Use this when: the main job is to restate, explain, re-render, repair, or compare something already written or published without quietly changing what it is about.
   You will leave with: a rewrite, explanation note, repair note, or bounded comparison note that keeps the object of talk stable.
   Start with: A.6.3.CR for same-entity retextualization, A.6.3.RT for representation-scheme transition, E.17.EFP for explanation-facing rendering, E.17.ID.CR for bounded comparative reading, and E.17.AUD.LHR / E.17.AUD.OOTD for local repair and authored-unit stability.

The older A.0 -> A.1-A.3 -> B.3 -> F.17 -> E.9 chain is not the universal default anymore. Use B.3 when assurance / trust / evidence transport is already part of the present burden, and use E.9 (DRR) when normative change or durable canon rationale must actually be published.

FPF is not:

• a shrink-wrapped project methodology;
• a quick-answer cheat sheet;
• a demand to read the whole specification linearly before doing useful work.

What stays outside this front door

• fuller route explanations live in Preface and Part J, not in the opening screen;
• longer step-by-step walkthroughs live in I.2, not in this README;
• advanced internal maps, AI-assistant prompt recipes, and extended examples appear later in this README or in "monolith" FPF-Spec.md in this repo; you do not need them before choosing your first route.

One-minute example

A vague project question:

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

Without FPF, this often becomes one overloaded discussion with mixed vocabularies, hidden trade-offs, and premature convergence on a single option.

With FPF, the work becomes a disciplined route:

problem framing -> bounded contexts (product / infrastructure / safety / evaluation) -> decision criteria (cost / latency / controllability / risk / time-to-value) -> portfolio of alternatives (buy / fine-tune / build / hybrid) -> evidence and test gaps -> starter DRR (a short decision record with reasons, assumptions, and open issues) -> starter UTS (a shared term sheet for risky or overloaded terms) -> aligned outputs for engineering / management / research / assurance

Result: one underlying body of reasoning, cleaner hand-offs between specialists, and a decision that can be reviewed, revised, and published without semantic drift.

Overview

The First Principles Framework (FPF) is a structured framework for thinking and coordinating work. It is written more like a technical specification than like a management book: there are named patterns, definitions, and review rules. Its job is to help teams model complex work, make reasoning inspectable, and keep decisions stable across engineering, research, and management.

This repository contains the core specification. Tooling belongs in tool-specific layers; worked examples, exercises, and guided learning paths belong in the pedagogical companion.

Use the spec as a reference model and route map, not as a linear textbook.

FPF is not a specific methodology such as Agile or Waterfall, and it is not a static encyclopedia. It is closer to an architecture for reasoning: a set of reusable patterns and working forms that help teams turn tacit thinking into shared, reviewable work.

FPF is not mainly about making one model smarter. It is about making collective reasoning usable: clear local contexts, explicit hand-offs, reviewable decision records, and outputs that different audiences can trust.

What problem FPF solves

FPF is most useful when strong local reasoning is no longer the main bottleneck. It is for situations where the hard part is coordinating specialised people and AI agents, keeping meaning stable across hand-offs, making trade-offs explicit, and presenting the same underlying work to engineers, managers, researchers, and auditors without semantic drift.

In plain language: FPF turns raw intelligence into work that is easier to align, review, evolve, and delegate.

It also helps teams create local zones of closure inside an open world, so a real decision can be made even when the outside remains uncertain.

Illustrative example: a platform team is deciding whether to buy, fine-tune, or build an agent stack. FPF helps separate product, safety, infrastructure, and evaluation contexts; define decision criteria; keep several options live long enough to compare them honestly; make missing evidence explicit; and publish one view for engineers and another for management without changing the underlying reasoning.

What you get after one pass

A first practical pass through FPF should leave you with concrete artefacts, not just better intuitions:

• a map of bounded contexts, hand-offs, and responsib