# Review the exception to the module contract

The unusual path often reveals whether a boundary is real. Inspect administrative operations, imports and reports that reach beyond the public API.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Pick a documented exception

Find a caller allowed to access another module's internals or data directly. Ask why the public contract does not meet its need and what rule the exception must preserve.

An exception can be justified, but it should have a purpose, owner and scope. A broad allowlist entry with no explanation tends to become a precedent for unrelated shortcuts.

Check whether the exception is still needed. A temporary migration path may remain long after the normal operation has been implemented.

## Follow its read and write access

Distinguish a read-only report from a mutation path. For writes, identify where the owning module's business invariants are enforced. If the answer is "the caller knows the rule", inspect how duplication is kept correct when the rule changes.

Review runtime database privileges and shared data-access helpers. A restricted import path does not prevent direct SQL through a broadly available connection.

Check user-level authority as well. Internal module access and permission to act on a particular target are separate requirements.

## Examine change coupling

Look at a recent rule change affecting the exception. Did the team remember to update both paths? Did tests fail if one was missed? This provides better evidence than a clean dependency diagram alone.

Inspect whether a missing public operation would remove the exception without exposing too much implementation detail. Avoid adding a generic repository export merely to make the dependency checker pass.

For reports, consider whether a dedicated read model would make the dependency explicit and stable. The goal is understandable coupling, not hiding all cross-module information behind unnecessary abstractions.

## Require a boundary failure test

Use a target state that should reject the operation and exercise the exceptional path. Inspect the final record and downstream effects. If the path intentionally overrides the rule, verify its separate authority and audit requirements.

Record the decision to retain, narrow or remove the exception. A module review is strongest when it examines the paths that do not fit the normal story, because those paths determine whether the owner can actually preserve its rules as the application evolves.

## Sources

- [Microsoft Learn: common web application architectures](https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures)
- [PostgreSQL: privileges](https://www.postgresql.org/docs/17/ddl-priv.html)