E.4.DPF:4.5 - Describe authoring dependencies when a named next use needs them

The dependency description is optional, minimal, and status-bearing. It records current dependency positions while later authoring results retain their actual status:

FrameworkAuthoringDependencyDescription:
  C2_1Identity:
    entityOfConcernRef: U.EpistemeRef
      = current DPF-authoring U.WorkPlan
    claimGraph: U.ClaimGraph
      = dependency-position claims and their availability, relevance, value,
        subject-pattern, acquisition-condition, and next-use-boundary claims
    effectiveReferenceScheme: U.ReferenceScheme
      = interpretation of those claims for the declared next authoring use
  claimScopeRef: ClaimScopeRef defined by A.2.6
  intendedReaderDescriptionRef: U.EpistemeRef
  intendedFirstUseDescriptionRef: U.EpistemeRef
  dependencyPositions[2..*]: FrameworkAuthoringDependencyPosition
  nextAuthoringUseBoundaryDescriptionRef: U.EpistemeRef
  modelUseStructureRef?: U.StructureRef
    only when one selected BoundedModelUseStructure changes interpretation for this use
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef)
    only for separately obtaining C.2.1 empirical-grounding relations

FrameworkAuthoringDependencyPosition:
  dependencyPositionKey: semantic key unique within claimGraph
  dependencyKind: FrameworkAuthoringDependencyKindValue
  dependencyAvailability: FrameworkAuthoringDependencyAvailabilityValue
  dependencyUseRelevance: FrameworkAuthoringDependencyUseRelevanceValue
  dependencyValueRef?: U.EntityRef
  dependencyValueKindRef?: U.KindRef
  dependencyPatternLocator: PatternID, a non-semantic locator for the pattern whose content defines, constrains, or tests this dependency
  dependencyAcquisitionConditionDescriptionRef?: U.EpistemeRef

FrameworkAuthoringDependencyDescription is a local use label for one C.2.1 episteme, and each FrameworkAuthoringDependencyPosition is a local ClaimGraph node form. Only the enclosing description is the episteme; each position is part of its ClaimGraph. The current authoring WorkPlan, one ClaimGraph, and effective ReferenceScheme supply the description’s identity. ClaimScope, reader and use descriptions, optional model-use structure, empirical grounding, provenance, assessment status, publication, and edition continuity remain separate. dependencyPatternLocator is an ordinary non-semantic PatternID that identifies the pattern whose content defines, constrains, or tests the dependency. A dependency that is also a MethodDescription identifies its episteme and the admitted Method it describes separately and applies the full A.3.2 test.

The minimum positions are one fpfEdition and one sourceBasis. For an available fpfEdition position, dependencyValueRef identifies the selected FPF edition; the next-use boundary names the Core claims required for the declared authoring use. A change to that edition or a material change to those claims reopens the affected use. Add another dependency kind only when the declared next authoring use relies on it or deliberately retains it for a named later use. A frameworkArchitectureAnswer position is optional: include it only when that use needs the accepted answer or its rationale, and point to the accepted answer and E.9 DRR rather than to a PFAD relation or record.

When dependencyAvailability=available, the exact dependency value and kind refs are present and the acquisition-condition description is absent. When dependencyAvailability=missing, those refs are absent and the acquisition-condition description is present. Relevance remains independent: missing + currentForNextAuthoringUse blocks the next use and opens the stated return, while missing + retainedForLaterUse does not block current work. Record a condition on using an available dependency in the pattern that defines the dependency or in the next-use boundary, not in the acquisition position.

As authoring proceeds, a dependency description may refer to an accepted framework-architecture answer and its E.9 DRR; E.4.PFR relation records and edition dependencies; G.2 source packs; subject-home NameCards; E.8 pattern drafts; E.24.PUB, E.11, or E.17 publication and access uses; E.4.DPF.DA evaluation results; E.23 improvement results; and G.11 currentness relations. Identify each dependency value, relation occurrence, evaluation result, edition relation, and receiving use separately, and apply the pattern that defines or constrains that object or use. The framework edition, package architecture, publication occurrence, publication form, carrier, dated authoring Work, and each dependency value retain their direct identities.