Foundations Introductory 2 minute read Updated 2026-06-26 UTC

The two Four-F frameworks

How to keep Fast/Flexible/Frugal/Federated distinct from Feed/Fork/Fight/Flee.

Research statusEditorial taxonomy from supplied reports Publication statePublished Reviewed byMichael Kappel Source reports3

Two useful meanings

The site uses two Four-F frameworks, and they should not be collapsed into one slogan.

Fast, Flexible, Frugal, Federated describes desirable system qualities. A system should respond quickly, adapt compositionally, conserve compute and energy, and coordinate across devices or organizations without centralizing everything.

Feed, Fork, Fight, Flee describes the evolutionary operating loop. It explains how evidence becomes variation, how variation is selected, and how losing variants leave the ecology.

Both matter. The first describes what a strong deployment feels like. The second describes how that deployment changes without becoming uncontrolled.

Comparison

FrameworkTypePrimary questionTypical ownerExample metric
FastqualityCan the system answer within the time budget?runtime/platformp95 latency
FlexiblequalityCan specialists be swapped or recomposed?architecturecontract compatibility rate
FrugalqualityDoes the result justify memory, energy, and cost?operationsjoules or dollars per accepted answer
FederatedqualityCan learning or inference distribute safely?privacy/platformlocal-data retention ratio
Feedlifecycle operationWhat evidence feeds adaptation?telemetry/dataaccepted evidence packets
Forklifecycle operationWhat controlled variants are explored?breeding pipelinecandidate count by operator
Fightlifecycle operationWhich variants survive evaluation?evaluator/governanceindependent scorecard pass rate
Fleelifecycle operationWhat exits the active ecology?release/runtimeretirements, rollbacks, unloads

Mapping qualities to operations

Fast systems need Flee because slow modules must be unloaded or routed around. Flexible systems need Fork because composition requires controlled variation. Frugal systems need Fight because cost must be evaluated against utility. Federated systems need Feed because each node contributes evidence under privacy and resource constraints.

pseudocode
FUNCTION map_quality_failure_to_lifecycle_action(observation)
    IF observation.type == "latency_regression"
        RETURN "FLEE: unload or bypass slow path"
    IF observation.type == "new_domain_gap"
        RETURN "FEED + FORK: collect cases and create specialist"
    IF observation.type == "cost_growth"
        RETURN "FIGHT: compare against no-op and retirement"
    IF observation.type == "federated_drift"
        RETURN "FEED: collect privacy-preserving local signals"
    RETURN "NOOP: monitor until evidence is sufficient"
END FUNCTION

Avoiding terminology sprawl

There are other useful Four-F lenses in the source reports, including Foundation/Frontier/Friction/Future and Factory/Facility/Field/Fleet. Treat those as audience-specific maps. The core engineering site should center on the two frameworks above because they connect directly to architecture and implementation decisions.

Design rule

Use Fast/Flexible/Frugal/Federated on product and architecture pages. Use Feed/Fork/Fight/Flee on evolution, release, and governance pages.

Source reports used for this guide

These reports are preserved verbatim in the site archive. The guide above is an editorial synthesis and may narrow, qualify, or reorganize claims from the source material.