Recon-Gen · Studio · Editor · Edit rail · SettlementAutoSettle (single-leg)

ⓘ Reference

A Rail is a money-movement contract — one well-known way value flows between roles. ACH origination, wire settlement, intra-day pool balancing, fee debits all live as Rails. Every transaction must match a rail by (rail_name, source_role, destination_role).

Required: name (unique identifier; chains, templates, and limit schedules all reference rails by this name — it doubles as the L1 matview's rail_name column value). Endpoint roles (source_role / destination_role) are edited on the rail itself after it's created — required for the validator to accept the rail as connected.

Single-leg rail requires:

leg_role + leg_direction (Debit / Credit / Variable).
A reconciler attachment — non-aggregating single-legs can't reconcile their own drift (SPEC §S3 + C3). Either attach to a TransferTemplate (closes its expected_net) or to an aggregating Rail (sweeps into its bundle). The Reconciler picker fieldset below handles this atomically with the save (BB.1). Exception: aggregating single-legs are self-reconciling and skip this requirement.
Variable-direction single-legs MUST attach to a TransferTemplate (validator C3); they can't sweep into an aggregating Rail. The template's expected_net determines this leg's amount at firing time.

Where this sits

Open full diagram →

Identity

Name *Unique rail identifier; referenced by chains + templates.

Description

Free-form prose; markdown OK.

Topology

Leg role *

MerchantPayableClearing

Role of the account the single leg posts to. Required on SingleLegRail.

Leg direction *Debit (money out) / Credit (money in) / Variable (direction + amount determined by enclosing template's ExpectedNet at posting time). Required on SingleLegRail.

Origin

OriginExternalForcePosted / InternalInitiated. See SPEC's Origin table.

Activity / cadence

Aggregatingtrue ⇒ rail fires on cadence (sweep / batch) and the bundles_activity / cadence fields apply. false ⇒ fires per-Transfer.

Cadence For aggregating rails (e.g. intraday-2h / daily-eod).

Bundles activity ?

No bundles activity selected yet — type below to add.

For aggregating rails only. Names the rails / templates whose Transactions this rail bundles. Type below to add; drag to reorder; × removes.

Metadata

Metadata keys ?

merchant_id
settlement_period

Metadata key names this rail's transactions carry. Pick from the L2-wide list or type a new one (e.g. ach_trace_number, wire_imad).

Posted requirements

Posted requirements One per line. Rail-specific fields the L1 PostedRequirements view requires beyond the auto-derived TransferKey + chain-Required fields (see derived.posted_requirements_for).

Aging

Max pending age

ISO 8601 duration (e.g. PT24H, PT4H, P1D). L1 Pending Aging flags any pending Transaction older than this. Empty ⇒ no watch.

Max unbundled age ?

ISO 8601 duration (e.g. P3D). L1 Unbundled Aging flags any Transaction older than this without a bundling parent. Empty ⇒ no watch.

Soft bounds

Typical amount range (min, max)Optional soft bound on per-firing abs(amount). Format: `min, max` (e.g. `5.00, 500.00`). Generator samples log-uniformly within this range, producing realistic demo amounts. Validator V1a-c rejects min≥max, non-positive values, and aggregating rails. Empty ⇒ falls back to per-kind lognormal heuristic.

Typical firings per period (min, max)Optional soft bound on how many times this rail fires per period. Format: `min, max` (defaults to per business day, e.g. `50, 500`) OR `period: min, max` where period is business_day | pay_period | week | month (e.g. `month: 80, 120`). Generator samples uniformly per period. Validator W1a-c rejects min>max, negatives, and aggregating rails. Empty ⇒ falls back to per-kind heuristic.

Cancel

In Use