Narrow interfaces: why the rail's power is what it refuses to carry.

The property

The console emits exactly one packet and the throttle consumes exactly that packet.

Narrowness here is a specific and checkable property: there is one transfer sheet, one set of destination cells, and no path by which the throttle reads anything from the console other than the declared fields. That constraint is what makes the handoff auditable — every deployment decision can be replayed from the packet contents, because the packet is provably everything the decision had to work with. An interface with side channels cannot make that claim, and a decision that cannot be replayed cannot really be reviewed.

The counterfactual

Broad visibility would have been easier to build and impossible to audit.

Consider the alternative that almost every spreadsheet system arrives at naturally: the throttle reads the console's Trade_Ledger directly, pulls a figure from the Dashboard when convenient, and references Open_Exposure for a detail the packet does not carry. Each connection solves a real problem at the moment it is added. Collectively they mean the throttle's output is a function of an undefined subset of the console's entire contents, and the question 'what did this decision depend on?' has no bounded answer. The rail's narrowness is the refusal of every one of those individually reasonable shortcuts.

The versioning payoff

A defined contract lets either side change without the other breaking.

Because the interface is declared rather than emergent, the console's internals can be rebuilt without touching the throttle, provided the packet still populates. That is why the workflow manual specifies the contract between Console v4.6 and Throttle v4.4C by field rather than by layout — the versions can advance independently as long as the six fields keep arriving at their destinations. A system with broad coupling has no equivalent freedom: changing anything in one workbook risks silently altering what the other reads, so in practice nothing gets changed at all.

The no-gap checklist

Narrowness is what makes verification a routine rather than an investigation.

The manual pairs the contract with a no-gap handoff checklist, and the checklist is only possible because the contract is short. Verifying six named fields against six named destinations is a task with a definite end, performable before live use in a couple of minutes. Verifying that two workbooks with broad mutual visibility are correctly connected is not a task at all — there is no list to check against, and the only available assurance is that nothing has obviously broken recently. A narrow interface converts correctness from something you hope for into something you confirm.

• Required fields are separated from optional audit/context fields, so the checklist has a clear minimum.
• Optional redundancy is allowed — the doctrine forbids undeclared channels, not useful context.
• The check runs before live use, not after a decision looks wrong.

The general principle

This is the same architecture the whole system runs on, at a smaller scale.

The rail's narrow interface is the module-boundary doctrine expressed between two specific workbooks. Each module has a defined role, defined inputs, and a defined boundary; data flows in declared directions; nothing lower overrides anything above. The deployment rail is where that principle is easiest to see concretely, because the boundary is a literal list of six fields rather than an abstraction — which makes it the best available worked example of what the architecture means when it says a module's inputs are defined.

The honest limit

A narrow interface can be narrow around the wrong six fields.

The doctrine guarantees auditability, not correctness. If a genuinely necessary input is missing from the packet, the throttle will produce decisions that are perfectly replayable and systematically uninformed, and the narrowness will do nothing to reveal it — a replay shows what the decision used, never what it lacked. This is why the contract's field list is itself a reviewable artifact rather than a settled one, and why the manual documents each field's purpose alongside its address: the justification is recorded so that the omission of anything comparable becomes noticeable.