E.4.DPF.DA:4.3a - DPF-wide package-form checks
Run this subpass when the declared use depends on an all-in-one DPF publication carrier, selected-host set, card set, skill-pack or index carrier, returned response artifact, MCP or other service route, retrieval or search route, assistant integration, or another reader-facing form. Inspect the exact publication form and U.PresentationCarrier that bears it, and inspect any service or route separately; do not substitute editable sources, a manifest, or a successful build run. These checks do not replace the twelve coordinates; they supply package-level evidence mainly for D1, D2, D4, D5, D7, D8, D9, D10, D11, and D12.
When the declared package use includes accepted-source integration or continuity with a predecessor publication, use a current E.4.PFIP conclusion as evidence for the affected coordinates. Keep the PFIP conclusion and the package-adequacy result separate: the first reports publication integration or continuity, and the second judges package adequacy for the declared use.
| Package-form check | Passing condition | Primary affected coordinates |
|---|---|---|
PFM1 First-entry functions and order | Before the pattern bodies, the exact reader-facing package has one search-oriented Table of Contents, one framework Readme that carries public first-entry situations and practical first results, and one Preface that explains their cross-cutting ideas, or consistently translated equivalents. Every pattern row in the ToC exposes its PatternID and title plus at least one working-question locator: a Use when cue, query phrase, or discriminating keyword; any domain or local PatternID prefix discipline is stated where the namespace can be disambiguated; admission state and dependencies appear when they can change the choice. Together these units let the reader recover a recognizable working situation, practical question, first useful result or blocker, direct PatternID or small plausible set, and stop or wrong-turn return without reading support apparatus first. Reader Guide, Pattern Index, or another synonymous parallel unit fails this check unless it has a genuinely different job and returns to the ToC or Readme that provides the entry. Display order does not become a prescribed pattern-use order. | D2, D5 |
PFM1a Practical-example declaration and card value | When the product publishes selectable practical examples, inspect its one key/form declaration and the actual Readme together. Every declared key has exactly one ordinary-entry or card occurrence, and no undeclared selectable occurrence or rival key list exists. The Readme says the examples are not a catalogue or coverage boundary and gives a route for unmatched questions. Every selected card passes E.11’s same-truthful-content-without-mantra comparison, uses the six fields in order, preserves a real multi-pattern dependency within the product’s mantra/card reading guard, returns to the direct patterns, and has at most one same-key expansion. Check at least one plausible direct example under the same use test. A zero-card result passes when smaller entries, locators, or guide answers support reliable choice and return. Syntax, length, topic inventory, PatternID count, or a historical heading proves neither card value nor product coverage. | D2, D5, D7, D8 |
PFM2 Pattern-language primacy | Pattern bodies remain the main language of use. Large maps, source-use tables, relation records, edition notes, and package architecture material appear after pattern bodies or in appendices or support sections unless they are a short first-entry aid. | D2, D5, D7 |
PFM3 Map discoverability | Every support map or appendix has at least one live entry route from ToC or readme, a pattern Relations section, low-value repair action, a condition that tells the reader when to revisit a source, or a package-refresh condition. A map that cannot be reached from work lowers package adequacy even if the map is correct. | D2, D5, D10 |
PFM4 Dependency direction | The DPF may cite FPF Core and explicitly depended-on upstream DPFs or local frameworks; FPF Core and the main monolith do not cite this DPF as required authority. If a DPF discovery belongs in Core, it returns through a Core amendment decision rather than a reverse dependency. | D4, D5, D9 |
PFM5 Publication, carrier, and access-route boundary | The framework episteme edition, package architecture, EpistemePublicationRelation occurrence, publication unit and form, exact U.PresentationCarrier, access route, actual access or use, readme, Preface, ToC, card set, maps, skill-pack or index carrier, returned response artifact, MCP service, retrieval or search route, and assistant integration remain separate. Visibility, storage, adjacency, callability, or a returned artifact establishes no framework truth, edition relation, package membership, source basis, quality result, admission status, process state, runtime dependency, Work authority, evidence use, or currentness. | D5, D9 |
PFM6 Public package naming | The public title and primary file or package name use a domain- or practice-specific framework name such as <DomainOrPractice> Principles Framework, with the domain or practice head visible. Principles Framework alone is only a kind or head phrase, not an individual framework name. Format slang such as local monolith, process state such as draft, and file-layout labels stay out of public package identity unless the carrier is explicitly a workspace-only artifact. | D1, D2, D5, D6, D9 |
PFM7 Development-state absence | Package carriers contain user-facing package content and durable package relations, not scattered draft, DRR, handoff, ledger, review-status, admission-blocker, helper-state, or process-run residue. | D5, D9, D10 |
PFM8 Cross-DPF relation discipline | References to another DPF or local framework state the exact dependency, specialization, source reuse, publication, selected-set, or other E.4.PFR relation and its refresh condition. Add a competing reading only when the visible relation form or observed use makes it plausible. | D4, D5, D9 |
PFM9 Normal-pattern maturity | Every pattern body claimed as part of a public, teaching, enterprise, or reliance-bearing DPF is a normal action-guiding FPF-style pattern for its declared use: it is drafted through E.8, evaluated through E.21, and not merely a heading skeleton, seed note, prompt output, compressed DRR recap, term sheet, ontology catalog, or commentary about the domain. When an all-in-one Markdown publication is presented as containing the full bodies, inspect that publication and require major publication units or Parts at H1, each PatternID and title at H2, canonical E.8 sections at H3, and every deeper source distinction at a distinct deeper level. A publication that demotes a body or merges two source heading levels does not pass as the full pattern body; neither does a card, summary, or other coarsened projection, even when the editable source body itself conforms. The pattern should show the typical problem, known failure mode or anti-pattern, SoTA-informed solution move, worked case, and boundary. Seeds are allowed only when the package status says seedOnly or the affected pattern is explicitly non-reliance-bearing. | D2, D5, D7, D8, D11 |
PFM10 Access-currentness and callable-use boundary | When access is in scope, name the exact skill-pack, index, or response U.PresentationCarrier separately from the MCP service, endpoint, retrieval or search route, or assistant integration that reaches or returns it. Expose framework edition, dependency, source and currentness boundary, bounded use, and refresh route; keep actual access or use as its own relation. Use C.35 for an exact generated or discovered result intended to inform architecture work, A.15 and the applicable tool or Work pattern for tool and Work claims, and the direct patterns for evidence, assurance, decision, currentness, and access claims. | D2, D5, D9, D10 |
PFM11 Carrier structure-account and controlled structural coarsening | A Readme, Preface, or equivalent first-entry form-bearing artifact provides a structure account: what the package exposes for whom, which domain or local structures and source denominator it foregrounds, what it deliberately coarsens, abstracts, omits, loses, or sends to appendices and sources, and when a reader must consult fuller pattern, source, evidence, or relation material. An MCP, search, retrieval, or assistant route may surface that artifact but is not its presentation carrier. In architecture-mediated narrative cases, trace the rendering on its carrier to the architecture description or view, then to the architecture as selected structures for the stated use, and finally to the wider source structures. Without a narrative rendering, trace the selected publication form on its carrier directly to the selected source structures. If entry begins at an access route, name the first form-bearing artifact or response and follow the same trace. Each step states selection, coarsening, abstraction, omission, preservation, loss, and return. | D1, D2, D5, D7, D8, D10, D11, D12 |
PFM12 Incremental common framework publication form | When the declared use includes a public all-in-one carrier or an independently publishable Readme, check only the E.11.PFP questions not already answered by PFM1: the stable public title and linked edition line or usable public locator; aggregate row-to-body agreement and duplicate PatternIDs across the one logical index; reserved support-index grammar; agreement of any repeated edition cue; the product-specific body and reference tail; and prohibited machine material or any development material not already disposed under PFM7. A visible authorship, date, dependency, language, access, maintenance status, support window, currentness window, or another explicitly named product value is required only when a declared reader decision or action needs it. Compare any visible cue or generated public projection with its edition or relation source, but do not require such a projection merely because generation is possible. DPF-specific pattern bodies and reference material remain under E.4.DPF. A form pass proves neither D12 field coverage nor overall package adequacy. | D5, D9 |
PFM1 owns practitioner entry, navigation, and the order in which readers meet the ToC, Readme, and Preface. PFM1a owns the product-native key/form declaration, the explicit examples-not-coverage boundary, and the content judgement that a mantra materially improves each selected cross-pattern card while a plausible direct example remains sufficient without one. PFM12 owns only the remaining common-form and edition-projection agreement. If one observation bears on PFM1, PFM7, or PFM12, record it once, point every affected disposition to the same evidence and repair, and lower an affected coordinate only once for that defect. Give the checks different dispositions only when they discriminate different defects with different repair actions.
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.