Distinguish Input Classes

BOUNDARY-DISTINGUISH-INPUT-CLASSES

Summary

Keep unknown, unsupported, denied, and preserved inputs in separate result or error paths. The distinction protects compatibility, authorization messaging, and recovery behavior while allowing small internal parsers to stay simpler.

Rule

Keep unknown, unsupported, denied, and preserved inputs distinct.

Why

Unknown, unsupported, denied, and preserved inputs require different treatment. A future-compatible unknown field may be preserved, an unsupported protocol shape should error, and denied input may need an authorization message. Collapsing them breaks compatibility and recovery.

Helps

  • Preserves compatibility semantics and gives callers actionable errors.

Limits

For small internal parsers, one error class may be enough. Preserve distinctions when callers, compatibility, security, or migration behavior depends on them.

Agent Instruction

Keep unknown, unsupported, denied, and preserved inputs distinct because each class needs different
treatment.

Mechanisms

Supported by typed parse results, error enums, compatibility fixtures, authorization tests, and docs that name preserved versus rejected input.

References