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:13476

    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 or evolved over time), it SHOULD be expressible as:

    • a TargetSignature: declared relation kinds + SlotSpecs + invariants and 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.EpistemeSlotRelation slots (C.2.1) it may read and write (SlotKind, ValueKind, and 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-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)