Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 08:25:59 UTC · snapshot created 2026-10-03 08:26:43 UTC · last check 2026-10-03 09:55:09 UTC

A.2.3:4.1 - Promise-content schema

U.PromiseContent : U.Episteme {
  content                  : U.ClaimGraph,
  promisedOutcomeSpecRef   : U.EpistemeRef, resolving to OutcomeSpec,
  effectiveReferenceScheme: U.ReferenceScheme,
  providerSystemRoleKindRef : U.KindRef,
  consumerSystemRoleKindRef?: U.KindRef,
  claimScope               : U.ClaimScope,
  accessSpec?              : U.MethodDescription,
  acceptanceSpec           : U.Episteme,
  unitOfDelivery?          : U.Episteme
}
  • content carries the promised-outcome, eligibility, and acceptance claims together with the optional accessSpec value when an access-method description is current; it is not an untyped text slot.
  • providerSystemRoleKindRef and consumerSystemRoleKindRef are promise-content fields typed by the existing U.KindRef; each resolves to one exact local system-role kind. accessSpec, acceptanceSpec, and unitOfDelivery are episteme values carried by value in the claim graph; a publication or other declared representation may express them through U.EpistemeRef values that resolve to those same epistemes without changing their kinds. Changing one of these content values or resolved kind references changes content and therefore the promise-content identity.
  • promisedOutcomeSpecRef resolves to the A.2.3:4.1.1 OutcomeSpec episteme.
  • effectiveReferenceScheme makes the claim graph and its references interpretable.
  • providerSystemRoleKindRef and consumerSystemRoleKindRef identify local work-facing kinds; actual providers and consumers enter only through named occurrences of directly declared species under U.SystemRoleAssignment.
  • claimScope is the exact U.ClaimScope over which the promise claims hold; it states the applicable operating conditions, populations, locales, and other admitted slices instead of leaving extent implicit.
  • accessSpec describes the access method enacted when the admitted holder system of an eligible consumer system-role assignment requests access; an access-point system remains separate.
  • acceptanceSpec states the acceptance criteria and selects the exact evaluation Method. It cites a MethodDescription edition only when the acceptance claim depends on that episteme’s claims. Evidence-admissibility conditions may be stated there; actual evidence-use relations remain separate.
  • unitOfDelivery states how accepted delivery work is counted when counting is current.
  • There is no generic modelUseStructureRef field. When an independently selected BoundedModelUseStructure changes one actually model-local receiving interpretation, the receiving assertion or use designates that structure separately; the structure neither identifies the promise content nor becomes an optional participant of PromiseContentUse. A genuinely structure-dependent relation species would require its own direct pattern, mandatory structure participant, stronger predicate, and occurrence-identity rule.
  • An internal delivery method remains U.Method. An already identified episteme is a U.MethodDescription only when its exact EntityOfConcern resolves to that Method and at least one claim says how that Method is done. A promise-content or acceptance claim may cite that episteme for one named use; Method-selection work, performed work, and PromiseContentUse remain separately governed.