E.4.PFR:4.2 - Framework edition dependency

Start with the readable dependency assertion. The edition labels below are illustrative; FPF@C1 contains the cited Core claims:

CodexProcessFramework@L1 depends on FPF@C1 for local process authoring: its revision guidance applies E.8:4.1.2, item 6, which requires repair of stale direct consumers in the same authoring increment; its evaluation guidance applies E.21:4.3’s rule for an adjacent-value rationale in each coordinate result. Removing or materially changing either claim reopens the corresponding local guidance. Changing the selected FPF edition also requires checking these dependencies.

Choose the representation from the receiver’s job. A cross-relation comparison may use one generic PFR row. An edition-impact or refresh receiver may use one dependency-specific record. This receiver needs the relied-on content and refresh fields, so it uses only the dependency record:

FrameworkEditionDependencyRecord@CodexProcessFramework:
  subjectAssertionRef: CodexProcessFramework-CoreDependencyAssertion
  dependencyPredicateClaimRef: E.4.PFR:3.4-framework-edition-dependency-predicate
  directionConstraintClaimRef: E.5.3-local-to-Core-direction-and-Core-acyclicity
  dependentEditionRef: CodexProcessFramework@L1
  reliedOnEditionRef: FPF@C1
  reliedOnContentRefs: ["FPF@C1 E.8:4.1.2 item 6", "FPF@C1 E.21:4.3 adjacent-value rationale rule"]
  namedUse: local_process_authoring
  dependencyDirection: CodexProcessFramework@L1 -> FPF@C1
  dependencyReason: the selected Core rules are required constraints on the affected local guidance; removing or relevantly changing them invalidates or reopens that guidance
  refreshConditionRefs: [FPF_edition_change_or_material_change_to_either_relied_on_claim_as_stated_above]

If one named cross-relation receiver also needs the generic view, add one PatternFrameworkRelationRecord, give both forms the same subjectAssertionRef, and set the dependency record’s genericRelationRecordRef to that row. In the generic row, relationFunctionClaimRef points to the E.4.PFR:3.4 dependency predicate, dependencyOrEditionEffect states the E.5.3-constrained direction, and refreshOrSupersessionCondition cites the G.11 refresh condition. Derive their shared endpoints, use, direction/effect, and refresh condition from the subject assertion. A change to that assertion refreshes both views together; neither carries an independently maintained copy of the dependency fact.

If this same pair also has a supported compatibility result for an overlapping use, state that C.2.1 assertion separately. Add its ref to compatibilityClaimRefs only when the named edition-impact receiver must traverse from this dependency record to that claim. The dependency record proves neither dependency nor compatibility, and E.5.3 does not own either edition.