Skip to content

Strict Bidirectional Contract Gate

Two-sided conformance protocol — instantiates Asymmetric Interface Tolerance Calibration

Enforces one strict contract in both directions — nothing off-spec may be sent or accepted — and routes the rare legitimate deviation through a named exception path rather than silent tolerance.

Most of this archetype is about choosing an asymmetry — strict here, liberal there. Strict Bidirectional Contract Gate is the deliberate refusal of that asymmetry: it holds both parties to the same strict contract, rejecting anything off-spec whether it is being emitted or received. Its defining move is to make tolerance a governed exception rather than an ambient default — the gate grants nothing, and any real need to deviate must pass through a named owner and a recorded waiver instead of being quietly absorbed at the parser. You reach for it precisely when a tolerated variant is not a convenience but a hazard, and when the cost of a silently-widened protocol is worse than the cost of an occasional hard rejection.

Example

A hospital's pharmacy system exchanges medication orders with the electronic health record over HL7. Here a "tolerant" interface is a liability: a dose unit the receiver silently reinterprets, a field it charitably fills in, is exactly how a milligram becomes a microgram. So the interface is a strict bidirectional gate. The EHR may only emit orders that fully conform — missing route, ambiguous unit, unbounded free-text dose: rejected at the source with a specific error. The pharmacy system may only accept orders that fully conform — it never guesses a missing field. When a genuinely new order type appears that the contract doesn't yet cover, it isn't quietly accepted; it's blocked, and the interface's named owner grants a time-boxed, logged exception while the contract is formally extended. Nothing dangerous slips through on politeness, and every deviation has a signature on it.

How it works

  • One contract, enforced symmetrically. The same conformance spec gates both directions; there is no "strict out, lenient in" relaxation — off-spec is off-spec regardless of who sent it.
  • Fail closed on doubt. Anything the contract doesn't clearly permit is refused, not charitably interpreted[1]; rejection is the default, and acceptance is the thing that must be earned.
  • No silent repair. The gate does not normalize or fill gaps; doing so would move the real contract into the parser where no one governs it.
  • Deviation by waiver only. A legitimate need to send or accept something off-spec is handled by an explicit, recorded exception from the named owner — never by loosening the gate for everyone.

Tuning parameters

  • Contract surface — how much of the exchange is under strict control versus left to a free-text or extension zone. More coverage means fewer dangerous ambiguities but more brittleness to benign variation.
  • Exception grant scope — whether a waiver is per-message, per-partner, or time-boxed, and who may authorize it. Tight scope preserves integrity; loose scope quietly recreates ambient tolerance.
  • Rejection blast radius — whether a nonconforming element fails the whole exchange or just the offending unit. Whole-message failure is safest and harshest.
  • Owner escalation path — how fast a blocked-but-legitimate case reaches someone who can decide, so strictness doesn't become a denial-of-service on real work.
  • Contract change cadence — how quickly a granted exception is folded back into the spec, so waivers are a bridge to the next version rather than a permanent shadow protocol.

When it helps, and when it misleads

Its strength is integrity under stakes: when a silently-tolerated variant can corrupt data, breach security, or harm someone, refusing everything off-contract in both directions is the only setting that keeps the written contract and the real contract identical. The governed exception path is what keeps that strictness from being brittle — deviation is possible, but only visibly and with an owner.

It misleads when applied to a large, diverse, loosely-coordinated ecosystem where most variation is harmless. There, strict-both turns benign difference into needless outage and pushes frustrated partners toward out-of-band workarounds — the very shadow protocol the gate was meant to prevent. Its classic misuse is bureaucratic capture: the exception path exists on paper but the owner is unreachable, so the gate becomes a wall — or, conversely, waivers are rubber-stamped until the "strict" contract is fiction. The discipline is to reserve this mechanism for interfaces where tolerance is genuinely dangerous, and to keep the exception path both real and cheap: fast to invoke, always recorded, and continuously drained back into the contract.

How it implements the components

  • integrity_and_security_risk_gate — the gate's whole purpose is to stop unsafe or off-contract data at the boundary in either direction; here, strictness is the integrity control.
  • strictness_owner_and_exception_path — it names who owns the contract and how a deviation is authorized, so tolerance is a signed, time-boxed waiver rather than an ambient default.

It does not set a deliberately liberal accept side (that's Tolerant Reader / Strict Writer Policy, the opposite regime), does not lint one party's outbound form in isolation (that's Strict Output Linter), and does not schedule a gradual tightening (Deprecation Warning and Tightening Schedule) — it is strict from the start.

References

[1] Fail-closed (fail-safe) — defaulting to the safe, restrictive state on any doubt or failure rather than the permissive one. A bidirectional contract gate is fail-closed by design: absent clear permission, the answer is no. ↩