Design a custom exception hierarchy callers can actually catch selectively

Design a custom exception hierarchy for the library or module described below. The goal is a hierarchy callers can actually catch selectively — not one flat exception class that forces every caller to catch everything the same way regardless of what actually failed.

MODULE
A library called "orderkit" that parses and validates e-commerce order export files.

FAILURE MODES
A malformed file that can't be parsed at all, a row with an invalid discount code, a row referencing a product ID that doesn't exist, a network timeout when checking a product ID against a remote catalog.

CALLER NEEDS
A malformed file should abort the whole import immediately; an invalid discount code or missing product should be logged and that one row skipped; a network timeout should trigger a retry, not a skip.

REQUIREMENTS
1. Define one base exception for this module/library (e.g. class OrderKitError(Exception)) that every other exception in it inherits from, so a caller who genuinely wants to catch anything this module can raise has one type to catch — but no caller should be forced to use that broad catch if A malformed file should abort the whole import immediately; an invalid discount code or missing product should be logged and that one row skipped; a network timeout should trigger a retry, not a skip. shows they need to react differently to different failures. If The main application defines AppError(Exception) at app/core/errors.py, and every internal library is expected to raise subclasses of it. names a project-wide base exception this library is expected to fit under, inherit from that instead of Exception directly, so a caller catching the whole application's error base still catches this module's failures too.
2. For each distinct failure mode in A malformed file that can't be parsed at all, a row with an invalid discount code, a row referencing a product ID that doesn't exist, a network timeout when checking a product ID against a remote catalog., create a specifically named subclass, not a generic one reused for multiple unrelated situations — a caller catching InvalidDiscountCodeError should never also silently catch a database connectivity failure because both happened to reuse the same exception type out of laziness.
3. Give each exception class the specific attributes a catcher would need to act on the failure programmatically, not just a human-readable message string — e.g. an InvalidDiscountCodeError should carry the actual code that was rejected as a real attribute, not only buried inside a formatted message a caller would have to regex out.
4. When raising a custom exception in response to catching a different underlying exception (a database driver's own exception, say), use raise CustomError(...) from original_exception, never a bare raise CustomError(...) that discards the original — losing the original exception's traceback and type is losing real debugging information for no benefit.
5. Decide deliberately whether any of A malformed file that can't be parsed at all, a row with an invalid discount code, a row referencing a product ID that doesn't exist, a network timeout when checking a product ID against a remote catalog. should be a subclass of a relevant Python builtin (a ValueError-like input problem might reasonably subclass ValueError too, using multiple inheritance, so callers who only know standard exception types still catch it correctly) versus purely custom — state the reasoning per exception, don't apply the same rule to all of them by default.
6. Document, in each exception class's docstring, exactly when it's raised and what a caller can safely assume about the state of the system after catching it (was anything partially written? is it safe to retry?).

OUTPUT FORMAT
1. The exception hierarchy, as a class diagram in text (indented to show inheritance) before the code.
2. The exception classes with their attributes and docstrings.
3. One example: a caller that catches two different subclasses differently, and one that catches the base class broadly, showing both are genuinely supported.