Relational Machine Port
What this is
The RelationalMachinePort is the step set Σ of a RelationalMachine.
Σ is a finite set. Each element s ∈ Σ is a RelationalHistoryStep — one irreducible input the machine can receive. The RelationalMachinePort is what a machine can accept; nothing outside Σ enters.
The RelationalMachinePort is not the history monoid. M(Σ, I) is the mathematical object generated from Σ under the independence relation I. The RelationalMachinePort is the presentation data — Σ and I — not the quotient structure those presentations generate. Knowing the RelationalMachinePort tells you what steps can enter. Knowing the history monoid tells you what histories those steps produce and which orderings are equivalent.
Two RelationalMachines can be connected only when their RelationalMachinePorts are compatible — when the steps one produces are steps the other can receive.
Mathematical grounding
Each s ∈ Σ generates a one-step history gen(s) ∈ T via the injective map gen : Σ → T defined in relational-history-step. Each step s also indexes a sequential comonad G_s on R (directed-comonad), the act of advancing the relational universe one step in direction s. The RelationalMachinePort is therefore what indexes the family of sequential acts {G_s}_{s ∈ Σ}.
In the FARS
In a FlatfileAgentialResourceSystem locale, the RelationalMachinePort is the set of FlatfileAgentialResourceSystemMessage types the locale’s INBOX.md can receive. The step alphabet Σ corresponds to {FixNeeded, GapFound, Discovery, Coordination} — the four message types defined in flatfile-agential-resource-system-message.
A RelationalMachinePort MUST be finite — the step set Σ must be a finite set, per the Axiom of Histories in relational-history-step. It MUST carry the independence relation I alongside Σ — the port is the pair (Σ, I), not Σ alone. It MUST be distinct from M(Σ, I) — the port presents the monoid, it is not the monoid.