# Complexity review

Use this brief before retaining a new service, integration, or exception. The purpose is to make its continuing attention visible.

**Proposed change / owner:** ____________________

**Reviewer (someone other than the builder):** ____________________  **Date:** ____________________

**Capability added:** ____________________

**Work, component, or exception removed:** ____________________

**Estimated attention per month once running (hours, by whom):** ____________________

| New dependency | Why needed | Who understands it | How failure is detected | How it is recovered | How it is updated or patched |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |
|  |  |  |  |  |  |

## Questions for the decision

- Can another person explain the normal path using the documentation?
- Which new accounts, renewals, credentials, or provider interfaces need attention?
- Does this create another authoritative copy of information?
- What happens when the original builder is unavailable?
- What is the simplest alternative that meets most of the need, and why was it rejected?
- What would cause the team to simplify or retire it?

## Evidence checked

- [ ] Documentation exists in the agreed location and was read by the reviewer, not only the builder.
- [ ] Credentials are in approved storage and are not tied to the builder's personal identity.
- [ ] Monitoring or a periodic check exists that would reveal silent failure.
- [ ] The change is recorded in the service ownership map or inventory.
- [ ] If this is an exception to a standard, the standard it departs from and the compensating measure are written down.

**Benefit that justifies the added responsibility:** ____________________

**Experiment boundary, access, and end date:** ____________________

**Decision:** retain / revise / continue experiment / retire

**Decision owner / next review:** ____________________

**Retirement or recovery path:** ____________________

## Register of retained complexity

Keep one line per retained item so the total is visible at each review.

| Item | Retained since | Owner | Monthly attention | Last reviewed | Retire trigger |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

## Common failure modes

- Experiments never end because nobody set an end date.
- The exception becomes the standard without anyone deciding so.
- Attention cost is counted only for the builder, not for support, security, and successors.
- Retirement is agreed but the accounts, credentials, and data remain.

This review covers ongoing attention. It does not replace the vendor review or the security review for the new component.