E.2.DA as DPF review | The package is judged against whole-FPF Pillars and domain adequacy is blurred. | Use E.4.DPF.DA; invoke E.2.DA only for FPF-level effects. |
E.21 averaging | Strong individual pattern scores hide weak package architecture. | Evaluate package coordinates directly; use E.21 only as evidence. |
| Source bibliography as adequacy | Sources are listed but do not change the package. | Apply G.2; carry adopted and rejected payload into pattern moves and boundaries. |
| Copied synthesis as assurance | The evaluation repeats C.32.MWA or E.23.CDI actions and treats completion as package adequacy. | Cite a completed result only where it changes a named coordinate; run D12 and the sequence-versus-simultaneity probe on the package itself. |
| Publication-form pass as semantic adequacy | PFM12 passes, so the package is called an adequate DPF without field-coverage evidence. | Keep form conformance as form evidence and judge D12 independently. |
| Duplicate first-entry charge | One ToC, Readme, Preface, or practical-entry defect is counted under both PFM1 and PFM12, lowering the same coordinate twice without a second repair. | Keep practitioner entry and navigation in PFM1; keep only incremental common-form and edition-projection agreement in PFM12; record the shared observation and repair once. |
| Publication carrier as package proof | The carrier is readable but relation, edition, source, and refresh structures are unrecoverable. | Add E.4.PFAD, E.4.PFR, source-use, quality, and refresh loci; keep the published artifact as carrier. |
| Invisible carrier structure-account | The carrier never tells what domain or local structure it selected, coarsened, abstracted, or omitted for the intended reader, so readers mistake the package for the domain itself or cannot judge coverage. | Add readme, Preface, ToC, skill-entry, or access-front-door carrier structure-account text, including where readers return for fuller sources and what structure the carrier does or does not preserve, then rerun PFM11. |
| Skill, route, or returned artifact as package proof | The package is callable, so a skill bundle, endpoint, route, or response is treated as proof of the framework edition, source, quality, or currentness. | Treat a form-bearing skill-pack, index, or response artifact as an exact U.PresentationCarrier; treat the service, endpoint, retrieval, search, or assistant integration as an access route; and keep actual access or use separate. Evaluate the framework edition and patterns through E.4.DPF.DA and E.21. Use E.4.PFR only when a named maintenance use needs a stable relation representation. |
| Skeleton patterns as package proof | The package has pattern headings and canonical sections, but the bodies do not teach a working reader what to do, how to judge boundaries, or how source payload changes action. | Treat the package as seedOnly, then harden each body through E.8 and E.21 before public or reliance-bearing use. |
| Ontology or conversation package as DPF | The package explains terms, roles, or ways to talk about the domain, but it does not help the intended practitioner resolve typical domain problems with SoTA moves. | Lower D7 and usually D11; keep the ontology or conversation guide as support material and add problem frames, solution moves, worked cases, and anti-pattern repairs. |
| Example inventory as coverage | A Readme lists many topics and the count is treated as proof that the framework serves its field. | Select a few examples for discoverability, say they are non-exhaustive, and judge actual field coverage under D12 through the pattern network, external results, representative use, and omissions. |
| Map hoarding | Huge maps appear before patterns and no work trigger leads to them. | Move maps after pattern bodies or make pattern relations and low-value repairs route to them. |
| Reverse dependency leak | FPF Core or the main monolith starts citing a DPF as required authority. | Move the claim into a Core amendment if it belongs in Core; otherwise keep the dependency one-directional from DPF to Core. |
| Process-state leakage | The package carrier includes draft, DRR, handoff, ledger, review, admission, or helper-state residue as package content. | Remove process state from package carriers and keep only durable user-facing package content, relation records, source-use boundaries, and refresh routes. |
| Seed promotion | A fast prompt result is treated as public DPF. | Mark seedOnly, name missing coordinates, and run E.23 hardening. |
Citation-driven 5 | Values rise because more sources, review proof, or maps were added. | Raise values only when action, source grounding, use of the applicable patterns, adoption, or refresh improves. |
| Evaluation table as Method, Work, result, or admission | Coordinate order or a filled table is treated as the evaluation Method, performed assessment, aggregate result episteme, favorable status use, or admission. | Recover the semantic Method and keep an ordinary judgement outside Work admission. Cite an exact A.6.1 application only when the assessment actually uses an operation declared by a separately admitted Mechanism and the receiving claim depends on its bindings; Work admission does not create it. When dated assessment U.Work is asserted, recover the exact actual evaluator System through A.13 and cite one independently valid A.15.1 Work account. Add the same obtaining A.13 assignment and F.6 only when the result expressly represents precise assignment-bound attribution; missing or failed F.6 leaves the Work intact. Then recover the coordinate claims, aggregate C.2.1 result, and any separate F.10 or E.19 receiving use. |