#Domain Principle Framework Package-Adequacy Evaluation CharacteristicSpace

E.4.DPF.DA · Stable · Evaluation (E) · Normative unless marked informative. · Part E - The FPF Constitution and Authoring Guides

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Evaluation (E) Status: Stable Normativity: Normative unless marked informative.

Use this pattern when a framework author, reviewer, steward, or AI agent must decide whether one Domain Principle Framework or Local Practice Framework package is good enough for one declared domain or local use.

#Relations

#Content

#Problem frame

Use this pattern when a framework author, reviewer, steward, or AI agent must decide whether one Domain Principle Framework or Local Practice Framework package is good enough for one declared domain or local use.

Primary EntityOfConcern: DPFPackageAdequacyEvaluation@Context, an authored evaluation over one bounded framework package edition. The package may be a DPF seed, selected pattern host set, all-in-one publication carrier, card set, skill pack, MCP-backed access service, source-pack-backed pattern family, or enterprise local practice framework edition. The first useful output is a coordinate table with values, short rationales, evidence loci, and repair proposals.

Do not use E.2.DA directly as the ordinary DPF package evaluation. E.2.DA asks whether FPF-level objects realize the FPF Pillars for broad FPF use. A DPF package has a narrower burden: it must serve one declared domain or local context while depending on FPF Core without redefining it. Use E.2.DA only when the DPF package changes or claims FPF-level Pillar adequacy.

Use E.21 for the quality of individual DPF pattern bodies. Use this pattern for the package as a whole: domain scope, source basis, Core dependency, DPF-wide publication-carrier form, pattern-set coverage, relation and edition records, local publication, evaluation route, refresh route, and adoption utility.

#Problem

DPF packages will often be produced quickly from source material, prompts, external literature, local practice, or generated candidates. Some are good enough as seeds; some can answer a domain question for an AI agent; some are public-ready publication carriers; some are only source summaries wearing pattern headings.

Without a DPF-specific adequacy evaluation, teams tend to use one of three wrong substitutes:

• they apply E.2.DA and ask whether the package is "FPF-like in general", even though the package is meant for one domain;
• they average E.21 scores of individual patterns and miss package-level failures such as missing source packs, broken dependency direction, poor first entry, or stale edition records;
• they inspect section presence and conclude that an all-in-one carrier, map, or seed package is adequate because it has patterns, a table of contents, a readme, a preface, maps, and sources.

The result is adoption risk. A reader may get a fluent local framework that does not know its domain boundary, does not preserve rival source traditions, duplicates FPF Core ontology, hides relation functions, has no refresh route, or cannot tell a practitioner what typical problem is live, which known failure mode to avoid, and which SoTA solution move to try first.

#Forces

#Solution

Evaluate one DPF package edition for one declared use through a DPF-specific adequacy characteristic space. The evaluation is derived from the shape of E.2.DA, but it is not the FPF Pillar evaluation. It asks whether the package realizes FPF-grounded domain value for a declared domain or local context.

DPFPackageAdequacyEvaluation@Context:
  evaluatedPackageRef:
  packageKind: domain-principle-framework | local-practice-framework | seed | selected-host-set | all-in-one-publication-carrier | skill-pack | mcp-backed-access-service | mixed
  declaredDomainOrLocalContext:
  intendedReaderOrOperator:
  declaredUse:
  nonUseBoundary:
  fpfCoreEditionRef:
  dependencyAndEditionRefs:
  sourceBasisRefs:
  pfadDecisionRefs:
  patternSetRefs:
  relationRecordRefs:
  publicationCarrierRefs:
  accessCarrierRefs:
  qualityEvidenceRefs:
  refreshRefs:
  evaluationEvidenceBasis:
  coordinateTable:
  protectedTradeoffSet:
  status:
  firstRepairOrNoProposalDisposition:
  reopenCondition:

#Ordinal scale

Default floor is 4 for public, teaching, enterprise, operational, or reliance-bearing DPF use. A fast seed or exploratory prompt output may use floor 3 only when non-use, missing evidence, and next repair are explicit.

#Required coordinates

Every E.4.DPF.DA run evaluates every coordinate below. Do not drop a coordinate because the package is "only a seed"; assign the value that the seed earns.

In this pattern, known failure modes means beginner mistakes and experienced-practitioner failures caused by stale, local-only, or non-SoTA practice. Do not narrow the check to novice errors only.

#Result row shape

An E.4.DPF.DA result uses this table shape:

A prose verdict, a checklist-count result, a table without evidence loci, or an average of E.21 pattern values is not an E.4.DPF.DA result.

#DPF-wide package-form checks

Run this subpass for any all-in-one DPF publication carrier, selected-host-set, card set, skill pack, MCP-backed access service, or package publication or access carrier. These checks do not replace the eleven coordinates; they supply package-level evidence mainly for D1, D2, D4, D5, D7, D8, D9, D10, and D11.

A failure in this subpass lowers the affected coordinate even when individual pattern bodies pass E.21. Repair the package carrier, relation record, first-entry route, dependency record, or support-map placement; do not copy the package-form proof into pattern bodies.

#Evidence basis and neighbouring owners

Use these owners instead of expanding this pattern into a package bureaucracy:

When a coordinate is below floor, return a finding or repair proposal. When a coordinate is at 4 and improvement is requested, search for a substantive non-dominated improvement. Do not raise a value by adding proof apparatus, more maps, more citations, or quality-status prose unless the package becomes easier to use, more source-grounded, more accurately bounded, or more refreshable.

#Status

#Archetypal Grounding

Tell: A personal-development DPF is generated in one short run. It may have useful principles and pattern seeds. E.4.DPF.DA can mark it seedOnly with high values for first-entry utility and low values for source-currentness, heterogeneous probes, relation records, or refresh. That is not failure; it is an honest package status and a next repair route.

Show: A domain DPF all-in-one publication carrier contains domain patterns, a source-use map, a Core-bridge map, relation records, and heterogeneous acceptance cases for several user situations. E.4.DPF.DA asks whether those cases actually force the pattern set to solve different domain problems, whether source rows changed pattern obligations, whether maps are reachable during work, and whether the package's local evaluation pattern can feed E.22/E.23 without becoming a hidden Core dependency.

Show: A hydroponic-cucumber DPF has excellent crop-control sources but no relation records and no first-entry carrier. E.21 may find that individual crop patterns are good, but D5PackageFormLayeringAndRelationAdequacy and D2DidacticEntryAndAdoptionAdequacy stay below floor until relation records and first-use routes exist.

Near miss: A DPF all-in-one publication carrier has a huge map before the pattern bodies. The map is correct but cold readers do not know when to open it. D2 and D5 fall unless pattern relations, low-value repair actions, or first-entry text route readers into the map from a real work trigger.

Near miss: A DPF has polished readme and Preface prose, but neither says what selected domain structure the publication/access expression exposes, what it deliberately coarsens or abstracts, or where a reader returns for fuller source and pattern detail. If the carrier is based on an architecture description, view, model, or graph, it also hides the fact that the intermediate source already selected and coarsened structure on the route source structures -> architecture -> architecture description or view -> publication/access expression. D1, D2, D5, D7, D8, and D11 fall because the carrier may be pleasant but its structure-capture claim is not inspectable.

#Bias-Annotation

The first drift is whole-FPF overreach: a DPF package is judged as if it had to cover every domain. Repair by declaring one domain or local context and evaluating adequacy for that context.

The second drift is local excellence laundering: good-looking patterns, a polished monolith, or generated fluency hides missing source, relation, edition, and refresh structures. Repair by evaluating the package coordinates, not only pattern bodies.

The third drift is quality proof leakage: evaluation results, review status, or package architecture evidence are copied into user-facing pattern prose. Repair by moving quality evidence to this evaluation, E.21, E.19, E.11, I.2, or publication evidence loci, and keep only the user-facing move or boundary in pattern bodies.

The fourth drift is invisible carrier narration: the package is presented as a transparent list of principles, so nobody asks which domain structures were selected, coarsened, abstracted, omitted, or already transformed through source structures -> architecture -> architecture description or view -> publication/access expression before the publication carrier was written. Repair by making the readme, Preface, or access front door provide a short carrier structure-account and checking it through PFM11.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

The pattern adds one package-level evaluation on top of individual pattern checks. The cost is worthwhile when DPF packages become reusable across domains, enterprises, AI-agent prompt packs, teaching materials, or local practice frameworks.

It also prevents a common false choice. A DPF seed can be useful without pretending to be public-ready, and a public-ready package can remain domain-bounded without pretending to be FPF Core.

#Rationale

FPF needed E.2.DA because a local edit can improve one pattern while harming the whole language. DPF packages need the analogous but narrower instrument: a package can have good patterns while failing as a domain framework. Domain source grounding, relation architecture, first-entry adoption, package publication, and refresh are package-level effects.

The coordinate set mirrors the spirit of the FPF Pillars but changes the adequacy question. FPF asks whether the whole framework remains broadly first-principle and cross-domain. A DPF asks whether one bounded domain or local framework is strong enough for its declared use while preserving dependency on FPF Core and source-return to its domain traditions.

#SoTA-Echoing

#Relations

• Builds on: A.19.ECS for evaluation characteristic-space construction.
• Specializes by object: E.2.DA supplies the adjacent form for complete multi-coordinate adequacy evaluation, but this pattern changes the evaluated object from FPF-level object to DPF package edition.
• Coordinates with: E.4, E.4.DPF, E.4.PFAD, and E.4.PFR for framework family, authoring spine, architecture decisions, relation records, edition dependencies, and package architecture.
• Coordinates with: G.2 and G.11 for source packs, source currentness, and refresh.
• Coordinates with: E.21, E.19, E.22, and E.23 for individual pattern quality, admission review, evaluation framing, and repeated improvement.
• Coordinates with: E.11, E.17, F.18, C.33, C.34, and C.35 for first entry, publication, naming, preservation, correspondence, and produced-carrier admission.
• Exits to: E.2.DA when a DPF package change claims FPF-level Pillar adequacy or proposes Core amendment effects.

#E.4.DPF.DA:End

Last Updated: 2026-06-30 — this section last modified in upstream FPF commit 9087581a (github.com/ailev/FPF)