FPF Reference

    A.6.P:4.10 — A.6.S compatibility note (ConstructorSignature is optional but canonical for engineered relation specialisations)

    Preface node heading:a-6-p-4-10-a-6-s-compatibility-note-constructorsignature-is-optional-but-canonical-for-engineered-relation-specialisations:12641

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    If an RPR‑pattern is applied as an engineered relation specialisation (created/evolved over time), it SHOULD be expressible as:

    • a TargetSignature: declared relation kinds + SlotSpecs + invariants/rules, and
    • a minimal ConstructorSignature: effect‑free operations that rewrite under‑specified prose into the explicit form and evolve relation records using the change‑class lexicon (mapped to A.6.5/A.6.6 canonical verbs).

    If a ConstructorSignature is provided, it SHOULD (conceptually) declare, for each constructor operation entry:

    • whether it is a species of A.6.2 / A.6.3 / A.6.4, and
    • which U.EpistemeSlotGraph slots (C.2.1) it may read and write (SlotKind/ValueKind/RefKind profile).

    Publication note (recommended). If the TargetSignature or relation-kind registry is published via MVPK, treat every face as a view (no new semantics), keep viewpoint accountability explicit, and prefer stable claim IDs (Claim Register) so downstream carriers cite claims rather than paraphrasing.

    Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)