Error Semantics

Fail-closed integration boundaries: explicit rejection instead of silent fallbacks

A bounded integration should reject an unknown or unsafe state explicitly rather than quietly selecting a similar path. MEMM treats version, configuration, capability and authorization failures as named outcomes so the host can distinguish “not supported” from “temporarily unavailable” or “not allowed”.

Topics:Fail ClosedTyped ErrorsCapability NegotiationSafetyRecovery

Examples of boundaries that should be explicit

  • Unknown API or profile version.
  • Missing required configuration.
  • Capability not present in the reviewed scope.
  • Authorization or policy decision denies execution.
  • Required dependency is not ready.

Why this helps long-lived OEM integrations

Typed rejection makes change visible to the host and reduces the risk that a future revision is mistaken for a compatible old behavior.

What this page explicitly does not claim: Fail-closed is an architecture principle, not a guarantee that every possible error or threat has already been modeled in every MEMM release.